CVE-2021-35464: ForgeRock Access Management (AM) Core Server Remote Code Execution Vulnerability

CVE-2021-35464 is a remote code execution vulnerability in ForgeRock Access Management (AM) Core Server. An unauthenticated attacker can send a specially crafted HTTP request to one of three specific endpoints and run code in the context of the account running the AM service. Because AM sits at the center of authentication and authorization for many enterprises, successful abuse can give an attacker a direct path into identity infrastructure. CISA has noted known ransomware use of this vulnerability, so organizations running ForgeRock AM should treat it as high priority.

How it works

The underlying weakness is CWE-502: deserialization of untrusted data. In products of this class, an application accepts serialized objects over the network and reconstructs them in memory without sufficient validation. When the deserialized data is attacker-controlled, the reconstruction process can be steered into invoking dangerous methods or loading attacker-chosen classes, resulting in arbitrary code execution.

According to the CISA summary, an attacker targets one of three ForgeRock AM endpoints—/ccversion/Version, /ccversion/Masthead, or /ccversion/ButtonFrame—with a specially crafted HTTP request. If the request is accepted and processed, code runs with the privileges of the AM process user. The vendor does not recommend running AM as root; when the service runs under a less-privileged account the immediate impact is limited to that account’s rights, though those rights are often still substantial inside an identity platform. Exact exploit mechanics and payload formats are not detailed here; defenders should obtain them only from the vendor advisory and trusted analysis.

Am I affected? How to find it in your systems

ForgeRock Access Management is typically deployed as a Java-based web application that provides single sign-on, federation, and policy enforcement. It commonly runs on application servers or containers inside DMZs or internal identity zones and is reached by browsers, mobile apps, and other services over HTTPS.

• Inventory every host, container, and load-balancer pool that serves ForgeRock AM. Check configuration management databases, software bills of materials, and package inventories for “ForgeRock AM,” “OpenAM,” or related core-server packages.
• Confirm the exact version and patch level against the vendor advisory; public detail supplied here does not list fixed or vulnerable version numbers.
• Search web-server and application logs for requests to /ccversion/Version, /ccversion/Masthead, or /ccversion/ButtonFrame, especially unusual POSTs or requests containing large or opaque binary/serialized bodies.
• Review process lists and file-integrity monitoring on AM hosts for unexpected child processes, new JAR files, or outbound connections initiated by the AM service account.
• If AM is exposed to the internet or to broad internal networks, treat it as higher risk until version and configuration are verified.

How to remediate

The primary action is to apply the updates provided by ForgeRock exactly as described in the vendor advisory. CISA’s required action is simply “Apply updates per vendor instructions.” After patching:

• Restart AM services in a controlled manner and verify that the three listed endpoints no longer accept the vulnerable request pattern (confirm test method with the vendor).
• Ensure AM runs under a dedicated, non-root service account with the minimum file-system and network privileges required.
• Disable or restrict any legacy or diagnostic endpoints that are not required for production use.
• Enforce strict input validation and, where the product supports it, disable Java deserialization of untrusted data or restrict the classes that may be deserialized.
• Rotate any credentials, keys, or secrets that the AM instance could have accessed while it was vulnerable.

If you can't patch immediately

If an emergency change window is unavailable, reduce exposure with compensating controls while you prepare the official update:

• Network segmentation: place AM behind an internal firewall or reverse proxy that permits only necessary source networks and blocks direct internet access to the management and version endpoints.
• Virtual patching / WAF: deploy rules that drop or challenge requests to /ccversion/Version, /ccversion/Masthead, and /ccversion/ButtonFrame, especially those with anomalous content types or serialized payloads. Tune rules against the vendor’s guidance to avoid breaking legitimate traffic.
• Disable the affected feature or endpoint if the product configuration allows it and business function is not impaired.
• Heighten monitoring: alert on any hit to the three paths, on unexpected process creation by the AM user, and on unusual outbound traffic from AM hosts. Retain full HTTP request logs for later forensics.
• Temporary credential hygiene: limit the AM service account’s rights and ensure it cannot reach sensitive data stores or domain-admin resources.

If your data may have been exposed

Actively exploited vulnerabilities, especially those with documented ransomware use, frequently precede broader compromise of identity systems and the data they protect. If you discover that a vulnerable AM instance was reachable and logs show suspicious requests to the listed endpoints, assume possible code execution and begin incident-response procedures: isolate the host, preserve memory and disk images, and hunt for persistence or lateral movement. As a quick additional check, you can run a free exposure scan of your email addresses against known breach data sets to see whether associated credentials have already appeared in public leaks.