CVE-2022-35914 is a remote code execution vulnerability in Teclib GLPI. CISA added it to the Known Exploited Vulnerabilities catalogue on 7 March 2023, which means attackers have used it in real attacks. Teclib GLPI contains a remote code execution vulnerability in the third-party library, htmlawed.
What makes this vulnerability dangerous in GLPI
CVE-2022-35914 is dangerous because remote code execution in a widely used web application can turn a single request path into full application compromise. In GLPI, that can mean attackers move from a vulnerable feature to direct command execution on the server that hosts the help desk platform.
When an RCE sits in a third-party component such as htmlawed, the immediate concern is not only the application layer but also the trust placed in bundled libraries. Review the vendor advisory for the exact affected build history and cross-check the record in the CVE Program and NIST National Vulnerability Database for authoritative record details.
How organisations assess exposure
Exposure checking starts with asset inventory: identify every internet-facing GLPI instance, every internal instance reachable by untrusted users, and every environment that may have inherited the vulnerable library through packaging or appliance-style deployment. Because exploitation depends on the application being reachable and vulnerable, inventory alone is not enough without knowing where the service is exposed.
Teams should also compare installed versions and deployment notes against the vendor advisory, then prioritise systems that support external portals, administrators, or integrations. For broader vulnerability triage and KEV-driven prioritisation, use the Vulnerability Management Guide as a process reference and treat KEV-listed issues as time-sensitive exposure, not routine backlog.
Remediation and compensating controls
The best outcome is to remove the vulnerable release or upgrade to the vendor-fixed state described in the advisory. If patching cannot happen immediately, reduce exposure by restricting network access, placing the application behind trusted access controls, limiting administrative reach, and disabling any path that lets untrusted input reach the vulnerable library more broadly than necessary.
For a web application RCE, compensating controls are about narrowing who can touch the service and how much damage a successful exploit can do. That usually means reducing internet exposure, segmenting the host, and treating the system as high priority until the vulnerable component is replaced or neutralised. The NIST Cybersecurity Framework 2.0 is useful here because its protect and respond functions reinforce exposure reduction, containment, and recovery discipline.
Detection and compromise review after patching
Once the issue is patched, assume the system may have been probed or compromised before remediation. Review web server logs, application logs, process creation events, shell history, scheduled tasks, new users, changed configuration files, and outbound network activity around the exposure window. If the host can execute commands, an attacker may also have used it to stage follow-on activity or steal application data.
Post-patch review should focus on what the server could access after exploitation, including service credentials, connected databases, and any trusted integrations. The MITRE ATT&CK Enterprise Matrix is a useful lens for mapping the likely follow-on behaviours, while the State of NHI & AI Agent Breach Report gives practical context for how compromise of application-hosted secrets can widen impact.
Risk and Threat Considerations
This class of vulnerability is especially risky because an externally reachable web application can become an execution point for the attacker, not just a data source. Once code execution is possible, the compromise can expand into persistence, lateral movement, secret theft, and abuse of the trusted position the application already has inside the network.
Failure mechanism: Exploitation of the vulnerable library lets an attacker run code through the GLPI process, then use that foothold to inspect files, harvest credentials, and pivot into adjacent systems or services.
Impact: The result can include takeover of the GLPI server, exposure of help desk data, theft of credentials or tokens, and broader internal compromise if the host has privileged network reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest Protection | RCE can expose stored application data and secrets. |
| DE.CM-01 — Networks and Network Services Monitored | Exposure review depends on monitoring traffic and service behaviour. | |
| RS.MA-01 — Incident Mitigation | An exploited RCE requires containment and remediation actions. | |
| Recommendation — Protect stored GLPI data and secrets with encryption and access restrictions. Monitor GLPI network and service activity for signs of exploitation. Contain the affected host and remediate the vulnerable GLPI deployment. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The term is a remediated software flaw with active exploitation. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-exploitation review depends on log analysis and correlation. | |
| Recommendation — Prioritise patching and verify the vulnerable GLPI component is removed or updated. Review application and host logs for evidence of exploitation and follow-on activity. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The CVE requires inventory, prioritisation, and remediation discipline. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Compensating controls reduce exposure when patching is delayed. | |
| Recommendation — Track GLPI exposure and remediate the vulnerable release on a priority basis. Harden and segment the GLPI host to reduce exploit impact. | ||
Practitioner Guidance
Why practitioners should care: Treat any KEV-listed RCE in a business-critical platform as a remediation priority, because the operational blast radius often extends beyond the application itself. Help desk systems can hold sensitive tickets, integrations, and administrator workflows, which makes post-exploitation impact larger than a simple service outage.
What to watch for: Look for unexpected child processes, new web-accessible files, unusual outbound connections, and changes to configuration or authentication material. If the vulnerable instance was exposed to the internet, assume it merits a compromise review even when you have not confirmed active exploitation.