CISA's required action for CVE-2022-28810 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 patching CVE-2022-28810 should look like in practice
The first job is inventory, not patching in the abstract. Locate every Zoho ManageEngine ADSelfService Plus instance, confirm whether it is internet reachable, and treat any exposed system as urgent because this was an exploited remote code execution flaw. If the vendor update is available, apply it exactly as directed by the product advisory rather than improvising a partial fix.
Patch and mitigation decisions should be tied to exposure. If you cannot apply the fix immediately, reduce the reachable attack surface by removing public exposure or taking the service offline until a supported remediation path exists. That is often safer than leaving a vulnerable identity portal exposed while waiting for a change window.
Because this is a remote code execution issue, the practical question is not only whether the product is present, but whether an attacker could still reach the vulnerable interface. A server hidden behind network controls may still be vulnerable if a reverse proxy, VPN path, or forgotten public route keeps it accessible. Confirm the actual attack path, not just the intended architecture.
How to validate whether exploitation may have happened already
After remediation, review the relevant logs for signs of earlier abuse. Look for suspicious requests, abnormal process launches, unexpected changes around the time of exposure, and any signs that the server was used as an execution point. This matters because exploited-in-the-wild flaws can be abused before defenders complete patching.
Do not limit the review to the product itself. Check adjacent telemetry such as endpoint detection data, authentication logs, web access logs, and file integrity or configuration change records. If the server was reachable from the internet, assume an attacker may have tried it repeatedly and look for evidence of follow-on activity, not just the initial request pattern.
Where logs or telemetry are incomplete, treat that as a risk signal rather than a clean bill of health. Absence of evidence in a short retention window does not rule out compromise, especially if the system was exposed during the exploit window and the product carried privileged access to account and identity workflows.
Why this vulnerability deserves a containment-first response
Remote code execution on an identity-adjacent management system can turn one vulnerable server into broader enterprise access. If an attacker gains code execution, the next step is often credential access, configuration tampering, or use of the application as a foothold for lateral movement. That makes patching necessary, but containment is what limits blast radius while patching is being done.
Strong exposed-asset discipline is the right response pattern for actively exploited vulnerabilities. NHIMG’s Zero-Day and Exploited Vulnerabilities Guide covers the operational sequence that fits this kind of case: identify exposure, prioritise by exploit activity, apply emergency mitigation, and then hunt for signs of compromise.
Risk and Threat Considerations
An internet-exposed RCE in an administrative application can create fast-moving compromise, because the same server that is used to administer identities may also sit close to sensitive credentials, sessions, or privileged workflows. The main danger is not only initial code execution, but the attacker using that execution to pivot into broader access before defenders complete remediation.
Failure mechanism: The attacker reaches the vulnerable service, executes code remotely, and uses the host as a foothold for persistence, credential access, or lateral movement before the issue is patched or isolated.
Impact: The organisation may face account abuse, unauthorized changes, service disruption, and a much larger incident than the original vulnerable application suggests.
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 governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This is an actively exploited CVE that requires discovery, prioritisation, remediation and verification. |
| Recommendation — Prioritise, patch and verify the vulnerable asset through continuous vulnerability management. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The subject is direct remediation of a product vulnerability with vendor-directed updates. |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure confirmation and post-fix validation depend on finding all affected instances. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-patch log review is central to checking for earlier exploitation. | |
| Recommendation — Apply vendor-directed remediation and track completion under flaw remediation. Scan for every exposed instance and validate remediation with follow-up vulnerability checks. Review relevant logs for signs of exploitation and escalate any suspicious activity. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded | The answer starts with finding every instance and understanding exposure. |
| Recommendation — Identify every deployed instance and record its exposure status before remediation. | ||
Practitioner Guidance
What to prioritise: Patch or isolate every exposed instance first, then work inward to less reachable systems. If you have multiple environments, do not let a lab or dev instance become the overlooked path back into production-like data or credentials.
What to verify: Confirm the update really removes the vulnerable condition and that the service is no longer internet reachable if patching is deferred. Then verify whether the host shows evidence of abnormal execution or post-exploit modification before declaring it clean.
Decision rule: If the fix cannot be applied quickly and safely, remove the service from exposure. For an exploited RCE, continued exposure is usually the higher-risk choice, even if the business prefers to keep the portal available.
Practitioner takeaway: Treat this as a containment and compromise-assessment problem as much as a patching problem, because the right outcome is not just a corrected version, but confidence that the vulnerable instance was not already used.
Related resources from NHI Mgmt Group
- Is CVE-2022-28810 (Zoho ManageEngine ADSelfService Plus Remote Code Execution) being exploited in the wild?
- CVE-2022-28810 (Zoho ManageEngine ADSelfService Plus Remote Code Execution)
- How do you patch or mitigate CVE-2022-26500 (Veeam Backup & Replication Remote Code Execution)?
- How do you patch or mitigate CVE-2022-26501 (Veeam Backup & Replication Remote Code Execution)?
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.
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