Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Maven

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

Also known asCVE-2026-33439
Published
Apr 7, 2026
Updated
Apr 7, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
org.openidentityplatform.openam:openam

Real-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 pointjato.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:latest Docker 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

  1. Apply WhitelistObjectInputStream filtering to ClientSession.deserializeAttributes(), matching the mitigation already applied to ConsoleViewBeanBase.deserializePageAttributes()
  2. Audit all callers of Encoder.deserialize() for user-controlled input
  3. Consider adding a JVM-wide JEP 290 deserialization filter as defense-in-depth

References


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

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
Mavenorg.openidentityplatform.openam:openamall versions16.0.6

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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.

  3. 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.

  4. 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

## 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., t
O3 Security · Impact-Aware SCA

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.