How do you patch or mitigate CVE-2022-35405 (Zoho ManageEngine Multiple Products Remote Code Execution)?

CISA’s required action for CVE-2022-35405 is to apply updates per vendor instructions. In practice, find every instance of Zoho ManageEngine 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 “patch or mitigate” means for this CVE

The practical response is to locate every Zoho ManageEngine instance, apply the vendor’s security update or documented mitigation, and treat the product as exposed until you confirm it is remediated. For an exploited RCE, the priority is not just patch deployment, but reducing reachable attack surface and verifying whether the flaw has already been used in your environment.

For a vulnerability already in CISA’s Known Exploited Vulnerabilities catalogue, patch timing should be treated as urgent operational work, not routine maintenance. If you need a broader playbook for active exploitation triage and post-patch validation, Zero-Day and Exploited Vulnerabilities Guide covers the response pattern from emergency mitigation through compromise assessment.

How to reduce exposure before the fix is fully in place

If patching cannot happen immediately, remove internet exposure first. Put the product behind trusted network boundaries, restrict access to administration paths, and disable any unnecessary remote reachability that could let an attacker reach the vulnerable code path. If the product is not essential, taking it out of service is safer than leaving a known-exploitable instance exposed.

When the application remains online during a maintenance window, assume the window itself is a risk period. Compensating controls should be practical and reversible: limit source IPs, enforce strict authentication around administrative interfaces, and verify that no redundant internet-facing endpoints remain. For teams already running a formal vulnerability programme, Vulnerability Management Guide provides the operational discipline for scoping, prioritisation, exceptions, and verification.

What to check after patching

After remediation, review logs for signs of earlier exploitation rather than assuming the patch closed the entire incident. Look for unexpected process launches, unfamiliar web requests, odd authentication activity, new files, suspicious child processes, or changes that do not match normal ManageEngine behaviour. With an RCE that was used in the wild, compromise checks matter as much as the patch itself.

If you find evidence of suspicious activity, widen the review to adjacent systems that the application could reach, because exploitation of a management product often creates a launch point into the rest of the environment. In that case, the question becomes containment and scoping, not only software repair. The CISA Known Exploited Vulnerabilities Catalog is the authoritative place to confirm the required action and keep remediation aligned with current federal guidance.

Risk and Threat Considerations

A remote code execution flaw in a widely deployed management platform is high-risk because it turns a trusted administrative product into an entry point for full system compromise. When the product is internet reachable, the attack path is short: find the exposed service, trigger the vulnerable function, and use the resulting execution to stage persistence, credential theft, or lateral movement.

Failure mechanism: The vulnerable code path can be reached remotely, allowing attacker-supplied input to execute in the product’s context and potentially inherit the access and trust of the managed environment.

Impact: Successful exploitation can lead to administrative takeover of the application host, downstream access to connected systems, and broader compromise if the product has privileged reach into infrastructure or management tooling.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation response depends on timely remediation and exposure reduction.
Recommendation — Prioritise and verify remediation for exploited internet-facing software.
NIST CSF 2.0	PR.PS-02 — Software, Services, and Hardware Acquired are Known, Installed, Configured, Monitored, and Maintained	Patch-and-mitigate actions require controlled maintenance of the vulnerable product.
	DE.CM-01 — Networks and Network Services Are Monitored to Find Potentially Adverse Events	Post-patch log review and exploitation checks rely on monitoring for suspicious activity.
Recommendation — Maintain the product through timely updates and configuration control. Monitor exposed services for signs of exploitation and follow-on activity.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The question is about remediating a known CVE and checking exposure across the estate.
	SI-2 — Flaw Remediation	Patching or documented mitigation is the core control response to the CVE.
Recommendation — Scan for every instance and track remediation until confirmed. Apply the vendor update or approved mitigation without delay.

Practitioner Guidance

What to prioritise: Inventory every Zoho ManageEngine deployment first, because untracked instances are the usual reason exploitable software survives a patch campaign. Separate exposed internet-facing systems from internally scoped ones so remediation order reflects actual blast radius.

What to verify: Confirm the fix landed on the running instance, not just that an update package was downloaded. Then verify that the service is no longer directly reachable from untrusted networks unless that exposure is explicitly required and controlled.

Decision rule: If you cannot patch quickly, reduce reachability immediately, and if you cannot reduce reachability safely, remove the product from service until the risk is bounded. For an actively exploited RCE, leaving it exposed while “monitoring first” is the wrong trade-off.

Practitioner takeaway: Treat this as an exploit-response problem, not a routine software-update task: patch, isolate, and then prove the environment was not already used as an attacker foothold.