Is CVE-2022-35914 (Teclib GLPI Remote Code Execution) being exploited in the wild?

What “exploited in the wild” means for CVE-2022-35914

For this CVE, the practical question is not whether the flaw exists, but whether it has crossed from disclosure into active abuse. CISA’s KEV listing is the strongest operational signal that exploitation is real, so the immediate task is to confirm exposure to Teclib GLPI and treat the issue as a live incident risk rather than a theoretical vulnerability.

That distinction matters because the response changes once exploitation is confirmed. You move from ordinary patch planning to urgent remediation, compensating controls, and compromise assessment. For public vulnerability intelligence and authoritative record details, use the CVE Program, the NIST National Vulnerability Database, and the CISA Known Exploited Vulnerabilities Catalog.

Because the flaw is a remote code execution issue in a third-party component, the practical security concern is not just application instability. If an attacker can reach the vulnerable path, they may be able to execute code on the affected system, which turns a software bug into a platform-level compromise risk. That makes inventory accuracy, external exposure, and dependency awareness central to the response.

How to confirm exposure and reduce blast radius

Start by identifying where GLPI is deployed, which internet-facing instances exist, and whether any environment still carries the vulnerable third-party library chain. If you cannot quickly prove that a system is out of scope, treat it as exposed until proven otherwise. The main operational failure here is hidden deployment sprawl, especially when the vulnerable component is bundled indirectly rather than tracked as a first-class asset.

Use vendor guidance for version-specific fixes and check the relevant deployment path rather than assuming a single software update step will cover every instance. If patching cannot happen immediately, isolate the system, restrict reachability, and remove any unnecessary administrative or remote access paths that would let exploitation become trivial. The FIRST EPSS resource can help you prioritise this kind of work alongside KEV status, but it should not replace the KEV signal itself.

Affected teams should also validate whether the vulnerable service has privileged access to adjacent systems, databases, or internal administrative tools. In practice, an RCE on a business application becomes much more serious when the application can reach sensitive internal resources or is reused across multiple environments.

What to check after remediation or delayed patching

Once exposure is identified, assume the possibility of post-exploitation activity until you have checked logs, file integrity, new user accounts, scheduled tasks, webshell indicators, unexpected child processes, and unusual outbound traffic. With RCE, the attacker goal is often persistence, credential capture, or lateral movement, not just one-time execution.

If the application uses service credentials, API keys, session material, or other secrets that could have been read from the host or process environment, rotate them as part of the response. That step is only necessary when those secrets may have been exposed, but when it applies, it matters more than a simple patch because the attacker may already have copied reusable access material.

For post-patch validation, compare what changed against what was actually observed before remediation. If you only confirm that the software is updated, you may miss signs that the system was already used as an execution foothold.

Risk and Threat Considerations

This vulnerability is high-risk because active exploitation means the attacker problem is no longer hypothetical. A remotely reachable RCE in a widely used business application can become an entry point for persistence, data access, or internal pivoting, especially if the host is trusted by other systems.

Failure mechanism: An attacker reaches the vulnerable code path in the htmlawed library, gains execution on the GLPI host, and then uses that foothold to plant persistence, inspect local secrets, or move laterally into connected systems.

Impact: The result can include application takeover, exposure of internal credentials or data, and a broader compromise if the server has privileged access or is used as an administrative jump point.

Practitioner Guidance

What to prioritise: Confirm whether any GLPI instance is internet-facing or otherwise reachable from untrusted networks, then treat those systems as the top remediation queue. KEV status should move this issue ahead of routine vulnerability backlogs.

What to verify: Verify the actual deployed version and dependency chain, not just the package name on an inventory sheet. For RCE issues, the vulnerable library path and exposure window matter more than the headline product name.

Escalation / exception: If you must delay patching, document the exception, narrow network access, and increase monitoring immediately. A delay without compensating controls is usually just deferred compromise.

Practitioner takeaway: Treat KEV-listed RCEs as compromise-risk events, not patch tickets, and validate for prior abuse before you declare the system clean.

Related resources from NHI Mgmt Group

• Guide: Zero-Day and Exploited Vulnerabilities Guide
• How do you patch or mitigate CVE-2022-35914 (Teclib GLPI Remote Code Execution)?
• CVE-2022-35914 (Teclib GLPI Remote Code Execution)
• Is CVE-2022-26501 (Veeam Backup & Replication Remote Code Execution) being exploited in the wild?
• Is CVE-2022-26500 (Veeam Backup & Replication Remote Code Execution) being exploited in the wild?