Is CVE-2021-35464 (ForgeRock Access Management (AM) Core Server Remote Code Execution) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2021-35464 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Any organisation running the affected product should treat remediation as urgent. Check exposure first, then patch or mitigate, then review logs for signs of earlier compromise.

What this means for an affected ForgeRock AM deployment

CVE-2021-35464 is not a theoretical issue to monitor casually. For an environment running the affected ForgeRock Access Management core server, the practical question is whether the vulnerable service is reachable and whether it has already been touched. Use the vendor advisory and CISA KEV listing to confirm the exact exposure profile, then move immediately to the shortest path to remediation.

Because CISA added the issue to KEV, the operational assumption should be that exploit activity is already credible. That changes prioritisation: treat it as an active-exploitation event, not a routine patch-cycle item. If the product is internet-facing or reachable through trusted internal paths, the exposure is materially higher and the review should be accelerated accordingly.

For older exploitation-driven flaws, the first useful distinction is between direct exposure and inherited exposure through a cluster, proxy, or shared administrative path. If you do not know where the vulnerable component sits in the request path, you do not yet know whether containment is complete.

How to verify exposure and reduce blast radius

Start by confirming where ForgeRock AM core server is deployed, which instances are reachable, and whether any surrounding controls are relying on assumptions that the application itself is trusted. The fastest containment win is often narrowing who can reach the service while the fix is being prepared.

If immediate patching is not possible, apply compensating controls that reduce inbound access, administrative reach, and lateral movement opportunities. In practice, that means restricting network exposure, tightening authentication paths around the application, and preserving logs so you can assess whether exploitation predates mitigation.

Zero-Day and Exploited Vulnerabilities Guide is useful here because it frames how to triage actively exploited issues, not just catalogue them. For prioritisation, pair that with the CISA KEV catalogue and exploit-likelihood signals such as EPSS when deciding which systems need same-day action.

Check for signs that the vulnerable server was already used as a foothold. For a server-side RCE issue, that means examining authentication events, process creation, web request patterns, outbound connections, and any unexpected changes in configuration or deployed artifacts. If compromise indicators exist, containment and investigation should proceed together rather than sequentially.

What to do if patching has to wait

When patching cannot happen immediately, the goal is not to make the risk disappear, but to keep the vulnerable service from becoming a simple exploitation target. Minimise exposure windows, remove unnecessary access paths, and ensure any exception is time-bound and owned by a specific team.

Keep a clear record of the compensating control in place, the reason patching is delayed, and the deadline for completing the fix. That matters because active exploitation changes the acceptable exception threshold, especially when the vulnerability is already in a government exploitation catalogue.

CISA Known Exploited Vulnerabilities Catalog is the right external reference for verifying the authoritative exploitation status and tracking the urgency of response. For deeper background on how to prioritise and verify remediation, NIST National Vulnerability Database provides the standard vulnerability record context, while FIRST EPSS helps teams compare exploitation likelihood across a larger queue.

If you delay remediation, compensate by narrowing access as much as possible and monitoring for abnormal use of the application. The point is to make exploitation harder and easier to notice, not to assume the delay is safe because the server is behind a perimeter control.

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	The question is about an actively exploited CVE and urgent remediation prioritisation.
Recommendation — Prioritise exposed assets for immediate remediation and verify the fix on all affected instances.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	Confirming exposure to a KEV-listed flaw depends on knowing where vulnerable assets exist.
	PR.IR-01 — Protection Processes and Procedures	The response hinges on timely patching or compensating controls for an exploited vulnerability.
	DE.CM-09 — Configuration Change Monitoring	Reviewing logs and configuration changes after possible exploitation is central to this CVE response.
Recommendation — Identify affected assets and map their exposure before deciding containment and remediation. Apply compensating controls and remediate the vulnerability as quickly as possible. Monitor for unexpected changes and investigate indicators of prior compromise.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This CVE requires vulnerability identification, prioritisation, and remediation tracking.
Recommendation — Continuously scan for the affected product and verify remediation status.

Practitioner Guidance

What to verify: Confirm whether the vulnerable ForgeRock AM core server is externally reachable, which business services depend on it, and whether logging is sufficient to support compromise review before you change anything.

Decision rule: If the affected instance supports authentication or access management in production, treat the issue as urgent remediation with immediate exposure reduction, not as a normal patch backlog item.

Common mistake: Teams often patch the product but skip the follow-up hunt for earlier abuse. For an exploited RCE, that leaves a gap between remediation and assurance that the environment was not already used for persistence.

Practitioner takeaway: For KEV-listed RCE flaws, the right order is exposure check, containment, remediation, then compromise review, because exploiting a known issue is often only the first step in a larger intrusion chain.

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