How do you patch or mitigate CVE-2022-35914 (Teclib GLPI Remote Code Execution)?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Cyber Security

CISA's required action for CVE-2022-35914 is to apply updates per vendor instructions. In practice, find every instance of Teclib GLPI in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What actually fixes CVE-2022-35914 in a real estate

The practical answer is inventory first, then remediation. You need to locate every Teclib GLPI instance, verify which ones are reachable from untrusted networks, and apply the vendor security update or documented mitigation. If you cannot patch promptly, remove the exposed service from the internet or take it out of service until a safe change window is available.

For exploited-in-the-wild flaws, the question is not only whether the product is patched, but whether the vulnerable path is still reachable. A patched system that remains unnecessarily exposed can still be a risk if the rollback path, adjacent service, or stale deployment keeps the vulnerable component reachable.

How to confirm exposure and prioritise the fix

Start with asset discovery and version confirmation, because patching blind spots are common when the same application exists in multiple environments, tiers, or test clones. Treat any internet-facing GLPI deployment as high priority until you have confirmed its exact state and reduced exposure.

Use a Zero-Day and Exploited Vulnerabilities Guide style workflow when a flaw is already being used in the wild: identify the affected asset, confirm whether the product is externally reachable, and move quickly from triage to containment rather than waiting for a perfect maintenance cycle. The same principle is reinforced by the Vulnerability Management Guide, which emphasises scope, prioritisation, exceptions, and verification.

For authoritative version and remediation details, use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog rather than relying on forum reposts or stale summaries.

Mitigation, validation, and post-patch hunting

Patch or mitigate as soon as operationally possible, then validate that the fix actually removed the vulnerable execution path. In practice that means checking the service version, confirming the mitigation is active, and verifying that the application is no longer internet-exposed if patching was deferred.

If the vendor fix cannot be applied immediately, the next-best control is to reduce attack surface, for example by placing the application behind VPN, restricting access to known admin networks, or disabling the service until remediation is complete. Temporary containment is only useful if it is enforced everywhere the application runs, including secondary nodes and disaster-recovery copies.

Because the flaw was used in the wild, review application, web, and system logs for prior exploitation after the fix is in place. Focus on unexpected requests, command execution indicators, new files, abnormal child processes, and any sign that the system was accessed before remediation.

Risk and Threat Considerations

Exploited remote code execution is dangerous because it can turn a public-facing business application into a foothold for full system compromise. Once an attacker can execute code, they may steal data, plant persistence, pivot laterally, or reuse the host for follow-on access.

Failure mechanism: The vulnerable GLPI instance remains reachable long enough for an attacker to trigger remote code execution before the patch or mitigation is applied, especially when multiple copies, clones, or stale deployments are overlooked.

Impact: Expect possible server compromise, data exposure, credential theft, and a need for incident response if logs or endpoint telemetry show signs of pre-patch abuse.

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	GV.RM-01 — Risk Management Strategy	Guides prioritising an exploited vulnerability by risk and exposure.
	ID.RA-05 — Threats, Vulnerabilities and Likelihoods Are Used to Inform Risk Response	Applies because active exploitation should drive response and containment choices.
Recommendation — Prioritise the exposed GLPI instance by risk and remediation urgency. Use active exploitation to drive faster containment and patching decisions.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Directly covers applying vendor security updates and handling vulnerable software.
	RA-5 — Vulnerability Monitoring and Scanning	Supports identifying all GLPI instances and confirming exposure before remediation.
	IR-4 — Incident Handling	Relevant because in-the-wild exploitation requires post-patch compromise assessment.
Recommendation — Apply the vendor update or documented mitigation and track completion. Scan and inventory all GLPI instances before and after remediation. Review logs and triage possible pre-patch exploitation as an incident.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Matches the need to find, prioritise and remediate an exploited vulnerability quickly.
	CIS-12 — Network Infrastructure Management	Supports removing internet exposure when patching must wait.
Recommendation — Triage, patch, and verify the vulnerable GLPI deployment quickly. Restrict network reachability until the fix is fully deployed.

Practitioner Guidance

What to prioritise: Treat every exposed GLPI instance as a remediation ticket with an owner, a deadline, and a verification step. If you cannot patch quickly, the decision should shift to containment first, not extended exposure.

What to verify: Confirm the vulnerable service is patched or isolated everywhere it exists, not just on the primary production host. Then verify log coverage is sufficient to detect whether the system was touched before remediation.

Practitioner takeaway: For an exploited RCE, the safe sequence is exposure reduction, fix application, then hunt for compromise, because delaying containment to preserve convenience is how routine patching becomes an incident.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org