Is CVE-2022-35405 (Zoho ManageEngine Multiple Products Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2022-35405 to its Known Exploited Vulnerabilities catalogue on 22 September 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Zoho ManageEngine PAM360, Password Manager Pro, and Access Manager Plus contain an unspecified vulnerability that allows for remote code execution.

What “exploited in the wild” means for this CVE

For a vulnerability question like this, the practical answer is not just whether a flaw exists, but whether credible exploitation evidence changes your response timeline. Once a CVE lands in CISA’s KEV catalogue, the issue has crossed from “monitor” into “treat as actively abused” and should be handled as an urgent exposure until you have confirmed remediation or a compensating control.

That shift matters because exploitation status changes triage priority, containment urgency and the depth of follow-up checks. The right question for defenders is not only “is it exploitable,” but “is it reachable in my environment, and has anything already touched it before I can patch?”

How to confirm exposure and narrow the blast radius

Start by identifying every instance of the affected Zoho ManageEngine products in your environment, including internet-facing systems, internal admin consoles and any remote management deployments that may have been forgotten. Then verify whether the vulnerable service is exposed to untrusted networks, whether it sits behind an application gateway or VPN, and whether administrative access has been constrained.

When the flaw is tied to remote code execution, exposure is not limited to the product itself. Review adjacent systems that trust the same host, credentials, or admin workflows, because a compromise often expands into nearby management tools, secrets stores, and privileged sessions faster than teams expect. The Vulnerability Management Guide is useful here because it frames KEV-driven prioritisation, exception handling, and post-remediation verification as one workflow rather than three separate tasks.

What to do if patching must wait

If immediate remediation is not possible, treat the system as high risk and reduce reachable attack paths before you defer the patch. That usually means removing public exposure, restricting admin access to tightly controlled networks, increasing monitoring for anomalous command execution or service behaviour, and validating whether any compensating control actually blocks the specific attack path, not just the login page.

For this class of issue, delaying the fix without a documented compensating control is usually a bad trade. Use the vendor advisory and the CISA KEV entry for version-specific patch details, then pair that with a temporary containment decision that is specific to your deployment model, not a generic “monitor closely” exception.

Risk and Threat Considerations

Remote code execution in an administrative product is especially dangerous because it can convert a management plane weakness into full host control, credential theft, and lateral movement. If the product is exposed to the network and reachable by an attacker, exploitation can become a fast path from initial access to privilege and persistence.

Failure mechanism: An attacker abuses the vulnerable management service to execute code on the host, then uses that foothold to enumerate trusted connections, steal secrets, and pivot into other systems that rely on the same administrative plane.

Impact: The likely outcome is broader compromise than a single application outage, because these tools often sit near privileged credentials, remote administration paths, and sensitive configuration data.

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 SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs require rapid identification, prioritisation and remediation.
Recommendation — Prioritise KEV-listed flaws for immediate remediation and verify closure with rescanning.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE requires prompt flaw remediation and validation of patched systems.
	IR-4 — Incident Handling	Active exploitation can require containment, hunting and compromise assessment.
Recommendation — Track, remediate, and verify the fix for the vulnerable Zoho ManageEngine products. Escalate the issue into incident handling when exploitation or compromise is suspected.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	KEV-listed exploitation makes vulnerability management and verification operationally urgent.
Recommendation — Apply vulnerability management procedures to identify, remediate, and verify exposure.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	You must identify where the vulnerable Zoho products exist before judging exposure.
	PR.IP-12 — Vulnerability management is implemented and maintained	The question is about handling an actively exploited vulnerability in operations.
Recommendation — Inventory the affected products and document where the vulnerable service is exposed. Use a maintained vulnerability-management process to accelerate patching and verification.

Practitioner Guidance

What to prioritise: Treat KEV-listed exploitation as an incident-response trigger, not a routine patch ticket. If the product is internet-facing or accessible from broad internal networks, prioritise containment and validation before lower-severity remediation work.

What to verify: Confirm whether the host shows signs of pre-patch compromise, including unexpected child processes, new services, modified configuration, unusual outbound traffic, or signs that administrative credentials may have been harvested. If compromise is plausible, investigate before rotating away the evidence.

Decision rule: If the vulnerable instance held privileged access, service credentials, or session material, rotate those secrets after containment and reimage or clean the host according to your incident standard. If it was isolated and showed no signs of abuse, verify patch success and preserve logs for a limited retrospective hunt.

Practitioner takeaway: With an actively exploited RCE in a management product, the real decision is how quickly you can prove the system is both patched and not already abused, because the exploit path often matters less than the trust and privilege it can inherit.