Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2022-28810 (Zoho ManageEngine ADSelfService Plus Remote Code…
Threats, Abuse & Incident Response

Is CVE-2022-28810 (Zoho ManageEngine ADSelfService Plus Remote Code Execution) being exploited in the wild?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2022-28810 to its Known Exploited Vulnerabilities catalogue on 7 March 2023, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Zoho ManageEngine ADSelfService Plus contains an unspecified vulnerability allowing for remote code execution when performing a password change or reset.

How to confirm active exploitation of CVE-2022-28810

For this vulnerability, the key signal is CISA’s KEV listing, because KEV inclusion means there is reliable evidence of exploitation in the wild. That makes the practical question less about whether attackers can use the flaw and more about whether your exposure still exists, whether the vulnerable product is reachable, and whether the system should be treated as an incident candidate until proven otherwise.

Start with exposure confirmation: identify every Zoho ManageEngine ADSelfService Plus instance, verify whether it is internet-facing or reachable from less-trusted networks, and check whether the system has been updated or otherwise remediated according to the vendor advisory and the KEV record. For triage and prioritisation, use the FIRST EPSS and the Zero-Day and Exploited Vulnerabilities Guide to separate “known exploited” from merely “known vulnerable” and to drive urgent remediation.

Because the issue affects password change or reset workflows, assess whether those paths have been used unusually, whether authentication logs show suspicious resets, and whether adjacent identity activity suggests follow-on access. Treat password-reset abuse as a plausible post-exploitation step, not just a product bug, and review for any evidence that attacker activity extended beyond the application into downstream accounts or directories.

Why the password reset path changes the operational risk

Password change and reset functions are privileged trust paths. If remote code execution is possible through those functions, an attacker may be able to reach the application without a traditional login path, and then pivot into the account lifecycle, session handling, or backend integrations that the product touches. That is why active exploitation matters even when the vulnerable service is not obviously a public attack surface.

The practical risk is not limited to the initial code execution. In a password-management context, compromise can expose credentials, sessions, configuration data, or management access that allows broader account takeover. When a product is used as part of enterprise identity operations, compromise can also create a path into other systems that trust its workflows or credentials.

Failure mechanism: the password reset or change workflow becomes an execution point, allowing attacker-controlled input to trigger arbitrary code on the server and potentially expose or alter identity-related material used by the application.

Impact: once the server is compromised, attackers may be able to harvest credentials, manipulate resets, maintain persistence, or move into connected systems that rely on the application’s trust relationships.

Use the Vulnerability Management Guide to keep the response disciplined: scope the asset, confirm exposure, verify remediation, and retain evidence of what was checked and when.

What to do if patching must wait

If remediation cannot happen immediately, reduce exposure rather than assuming the vulnerability is merely deferred. Restrict network access to the application, remove unnecessary internet reachability, segment it from admin and directory services where possible, and increase monitoring on the host and surrounding authentication paths. If the system cannot be isolated, treat it as a higher-risk exception with explicit sign-off.

Also review whether the application holds or can access sensitive credentials, service accounts, or session material that would increase blast radius if the server were compromised. If those materials are present, priority should shift to limiting their scope and planning rotation after remediation, especially if there is any sign of suspicious activity. For a broader exploitation playbook, Gladinet Hard-Coded Keys RCE Exploitation shows how an RCE issue can quickly become a credential and access problem, not just an application problem.

Before trusting the system again, validate whether logs, process creation, outbound connections, or account changes indicate earlier compromise. If the application handled sensitive resets or identity operations while vulnerable, consider credential and session rotation for the affected environment, not just a code fix.

Risk and Threat Considerations

This vulnerability is risky because it sits on a workflow that users and administrators often trust. A remotely exploitable flaw in password reset or change logic can be attractive to attackers because it may sit close to identity controls, and those paths often have high-value downstream access even when the application itself is not the final target.

Failure mechanism: an attacker abuses the reset or change workflow to execute code on the server, then leverages the compromised application to reach credentials, sessions, or trusted integrations.

Impact: the compromise can extend beyond the application into account takeover, persistence, lateral movement, or exposure of other systems that depend on the product’s trust boundary.

Standards & Framework Alignment

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

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

FrameworkControl / ReferenceRelevance
NIST SP 800-53 Rev 5SI-2 — Flaw RemediationCVE remediation and verification are central to this actively exploited flaw.
AU-6 — Audit Record Review, Analysis, and ReportingThe flaw can be investigated through logs for signs of exploitation and abnormal reset activity.
Recommendation — Prioritise remediation, verify the fix, and track the vulnerable instance until exposure is closed. Review authentication and application logs for evidence of exploitation and follow-on activity.
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementKEV-listed exploitation requires rapid identification, prioritisation, and remediation of affected assets.
CIS-8 — Audit Log ManagementChecking for earlier compromise depends on preserving and reviewing application and auth logs.
Recommendation — Identify exposed instances quickly and drive urgent remediation based on active exploitation. Retain and review logs for suspicious reset, login, and host activity around the exposure window.
NIST CSF 2.0PR.AA-05 — Protective TechnologyAccess restriction and segmentation reduce exposure while remediation is pending.
DE.CM-03 — Anomalies and Events Are DetectedDetection of anomalous reset and host activity supports compromise assessment for this exploited flaw.
Recommendation — Restrict network reachability and segment the affected system until remediation is complete. Monitor for abnormal password-reset, authentication, and host events tied to the vulnerable service.
OWASP ASVSV6 — AuthenticationThe issue sits in password change and reset logic, making authentication workflows directly relevant.
Recommendation — Verify reset and change workflows are protected and that abnormal auth activity is investigated.

Practitioner Guidance

What to verify: confirm the exact deployment, whether the instance is externally reachable, whether vendor remediation has been applied, and whether authentication or reset logs show anomalous activity around the exposure window.

Decision rule: if the system handled password resets while unpatched, treat the case as both a vulnerability-remediation task and a compromise-assessment task, because the identity workflows may already have been abused.

Practitioner takeaway: For KEV-listed vulnerabilities, the question is not only “is it exploitable?”, but “did exploitation already happen here, and what identity material should be rotated or reviewed because of it?”

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