CVE-2021-35464: ForgeRock AM (OpenAM) unauthenticated Java deserialization RCE, ransomware-exploited
The short version: ForgeRock AM (formerly OpenAM) — an identity and access-management gateway — has a Java deserialization flaw (CVE-2021-35464) that lets an unauthenticated attacker execute code by sending a single crafted request to a /ccversion/* endpoint. It scores 9.8, it was exploited by ransomware operators, and it's in CISA's Known Exploited Vulnerabilities catalog with an EPSS at the very top of the scale. If you run an affected build exposed, this is patch-and-verify. Steady hands — but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice and on paper |
| CVSS v3.1 (NVD) | 9.8 — Critical · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H |
| EPSS | ~99.99% · 99.99th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation was due 2021-11-17 |
| Known exploited? | Yes — mass exploitation, including ransomware operators |
| Vulnerability type | CWE-502 deserialization of untrusted data → unauthenticated remote code execution |
| Requires authenticated session? | No — pre-authentication (via /ccversion/*) |
| Affected | ForgeRock AM (OpenAM) server before 7.0, using the Sun ONE Application Framework (JATO) on Java 8 or earlier |
| Fixed in | ForgeRock AM 7.0+; a vendor patch/workaround exists for supported earlier releases (see ForgeRock KB a47894244) |
What you need to know
CVE-2021-35464 is a Java deserialization flaw stemming from ForgeRock AM's use of the legacy Sun ONE Application Framework (JATO). An unauthenticated attacker sends a single crafted request to a /ccversion/* endpoint (Version, Masthead, or ButtonFrame), the server deserializes attacker-controlled data, and that turns into remote code execution — in the context of the account running AM (which is why the vendor recommends never running it as root).
This is about as bad as external exposure gets, and the target sharpens it:
- It's an identity gateway. AM fronts authentication and SSO for other applications — compromise there can cascade into everything it protects.
- It's pre-authentication and trivially reachable. These endpoints are exposed by design; no credential, no chain.
- It was live and weaponized. It saw mass exploitation and was used by ransomware operators, and its EPSS sits at the very top of the scale.
How serious we see it
High — the 9.8 is not hyperbole here.
Unauthenticated, network-reachable code execution on an identity and access-management server, confirmed exploited by ransomware crews, is the definition of top-of-queue. The bounded, reassuring part is that it's specific and fixable: it affects AM builds before 7.0 using the legacy JATO framework, and both an upgrade and a vendor workaround are available. The catch is the same as any long-exploited flaw — being patched and being clean are separate questions, so verify you weren't already touched.
Recommendations
Straight from ForgeRock's advisory and CISA:
- Patch or upgrade now. Move to ForgeRock AM 7.0+, or apply the vendor's patch/workaround for your supported release (ForgeRock KB a47894244).
- Assume nothing given the long exploitation window — hunt. Review logs for requests to
/ccversion/Version,/ccversion/Masthead, and/ccversion/ButtonFrame, and for unexpected process execution. - If you find indicators, respond fully. Rebuild the server if warranted, and rotate all credentials, keys, and SSO/session secrets it held — an IAM compromise reaches far.
- Harden exposure. Restrict access to the
/ccversion/*endpoints and the AM console; never expose more of the management surface than necessary. - Confirm your exposure first. Verify whether you run an affected AM/OpenAM build reachable from the internet.
How BreachRisk sees it
BreachRisk starts from the outside, the way an attacker does. From little more than your domain it discovers internet-facing ForgeRock AM / OpenAM interfaces, fingerprints the product and version, and flags exposure tied to KEV-listed, ransomware-exploited vulnerabilities like this one — pushed to the top of your results because it's in KEV and because unauthenticated RCE on an identity gateway earns it.
That continuous, attacker's-eye view is the whole point for identity infrastructure: the exposed gateway is already mapped, so when a flaw like this surfaces you go straight to patch-and-verify instead of starting with an inventory.