GHSA-2cqq-rpvq-g5qj
GHSA-2cqq-rpvq-g5qj is a Deserialization of Untrusted Data vulnerability in org.openidentityplatform.openam:openam. O3 Security confirms whether GHSA-2cqq-rpvq-g5qj is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OpenIdentityPlatform OpenAM: Pre-Authentication Remote Code Execution via `jato.clientSession` Deserialization in OpenAM
Blast Radius
org.openidentityplatform.openam:openamReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Summary
OpenIdentityPlatform OpenAM 16.0.5 (and likely earlier versions) is vulnerable to pre-authentication Remote Code Execution (RCE) via unsafe Java deserialization of the jato.clientSession HTTP parameter. This bypasses the WhitelistObjectInputStream mitigation that was applied to the jato.pageSession parameter after CVE-2021-35464.
An unauthenticated attacker can achieve arbitrary command execution on the server by sending a crafted serialized Java object as the jato.clientSession GET/POST parameter to any JATO ViewBean endpoint whose JSP contains <jato:form> tags (e.g., the Password Reset pages).
Vulnerability Details
Background
CVE-2021-35464 identified that the jato.pageSession HTTP parameter was deserialized without class filtering, allowing pre-auth RCE.
OpenIdentityPlatform OpenAM mitigated this by introducing WhitelistObjectInputStream in ConsoleViewBeanBase.deserializePageAttributes(), which restricts jato.pageSession deserialization to a hardcoded whitelist of ~40 safe classes.
However, the JATO framework contains a second deserialization entry point — jato.clientSession — handled by ClientSession.deserializeAttributes(). This code path was not patched and still uses the unfiltered Encoder.deserialize() → ApplicationObjectInputStream, which performs ObjectInputStream.readObject() with no class whitelist.
Root Cause
ClientSession.deserializeAttributes()
→ Encoder.deserialize()
→ ApplicationObjectInputStream.readObject() // VULNERABLE — no whitelist
The ClientSession object is instantiated in RequestContextImpl.getClientSession() with the raw jato.clientSession parameter value from the HTTP request. Deserialization is triggered during JSP rendering when <jato:form> tags invoke getClientSession() → hasAttributes() → getEncodedString() → isValid() → ensureAttributes() → deserializeAttributes().
Affected Code
File: com/iplanet/jato/ClientSession.java
protected ClientSession(RequestContext context) {
this.encodedSessionString =
context.getRequest().getParameter("jato.clientSession");
}
protected void deserializeAttributes() {
if (this.encodedSessionString != null
&& this.encodedSessionString.trim().length() > 0) {
this.setAttributes(
(Map) Encoder.deserialize(
Encoder.decodeHttp64(this.encodedSessionString), false)
);
}
}
Gadget Chain
The exploit uses classes bundled in the OpenAM WAR:
PriorityQueue.readObject() [java.util — JDK]
→ heapify() → siftDown() → comparator.compare()
→ Column$ColumnComparator.compare() [openam-core-16.0.5.jar]
→ Column.getProperty()
→ PropertyUtils.getObjectPropertyValue() [openam-core-16.0.5.jar]
→ Method.invoke(TemplatesImpl, "getOutputProperties")
→ TemplatesImpl.getOutputProperties() [xalan-2.7.3.jar]
→ newTransformer() → defineTransletClasses()
→ TransletClassLoader.defineClass(_bytecodes)
→ _class[_transletIndex].newInstance()
→ EvilTranslet.<clinit>() [attacker bytecode]
→ Runtime.getRuntime().exec(cmd)
Impact
- Pre-authentication — no credentials or session tokens required
- Remote Code Execution — arbitrary OS commands as the application server user
- Full server compromise, lateral movement, data exfiltration
- Affects any deployment with at least one accessible JATO endpoint whose JSP renders
<jato:form>tags (e.g., Password Reset pages)
Tested Environment
- OpenIdentityPlatform OpenAM 16.0.5 (official release WAR from GitHub)
- Apache Tomcat 10.1.52
- Java 21.0.7 (Oracle JDK)
- macOS / Linux (aarch64)
- Also verified on
openidentityplatform/openam:latestDocker image (Java 25)
Affected Versions
- OpenIdentityPlatform OpenAM 16.0.5 (confirmed on both Docker and bare-metal Tomcat)
- Likely all versions that left
ClientSession.deserializeAttributes()unpatched
Remediation
- Apply
WhitelistObjectInputStreamfiltering toClientSession.deserializeAttributes(), matching the mitigation already applied toConsoleViewBeanBase.deserializePageAttributes() - Audit all callers of
Encoder.deserialize()for user-controlled input - Consider adding a JVM-wide JEP 290 deserialization filter as defense-in-depth
References
- CVE-2021-35464 — Pre-auth RCE in ForgeRock OpenAM (PortSwigger Research)
- https://portswigger.net/research/pre-auth-rce-in-forgerock-openam-cve-2021-35464
- CWE-502: Deserialization of Untrusted Data
Credit
This finding was discovered by Rahul Maini and Hacktron AI while auditing OpenIdentityPlatform OpenAM. Hacktron AI is our white-box pentest solution, designed to deliver high-accuracy results with minimal false positives.
Disclosure Policy
This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public on the day that the fix was made available or an earlier or later date if agreed by both parties. Otherwise, this bug report will become public at the deadline.
If another researcher discloses the proof-of-concept before any deadlines, we reserve the right to publish our findings.
The details of this bug may be privately disclosed to vulnerable parties, including but not limited to Hacktron AI's customers.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.openidentityplatform.openam:openam | all versions | 16.0.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.openidentityplatform.openam:openam. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update org.openidentityplatform.openam:openam to 16.0.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2cqq-rpvq-g5qj is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-2cqq-rpvq-g5qj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-2cqq-rpvq-g5qj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-2cqq-rpvq-g5qj in your dependencies?
O3 detects GHSA-2cqq-rpvq-g5qj across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.