CVE-2026-33439: Pre-Authentication Remote Code Execution in OpenAM via JATO clientSession Deserialization

OpenIdentityPlatform OpenAM contains a severe pre-authentication Remote Code Execution vulnerability due to insecure object deserialization within its JATO framework integration. The issue resides specifically in the handling of the jato.clientSession HTTP parameter. Any endpoint exposing JATO ViewBeans via <jato:form> tags provides a direct vector for exploitation. Common targets include unauthenticated pages such as the Password Reset or User Registration interfaces.

This vulnerability is classified under CWE-502: Deserialization of Untrusted Data. The framework receives user-supplied data from the HTTP request, performs Base64 decoding, and passes the resulting byte stream to a Java ObjectInputStream. Because the system fails to validate the class types being instantiated during this process, an attacker can supply objects that invoke malicious behaviors upon deserialization.

Historically, OpenAM suffered from an identical flaw (CVE-2021-35464) involving the jato.pageSession parameter. The vendor addressed that previous vulnerability by introducing a WhitelistObjectInputStream to restrict deserialization. However, the jato.clientSession parameter was omitted from this hardening effort, leaving the exact same attack surface exposed through an alternate variable name.

The vulnerability originates in the initialization of the ClientSession object. When a request is processed, the RequestContextImpl.getClientSession() method parses the HTTP request to extract the jato.clientSession parameter. This parameter is designed to maintain state across client requests, but the implementation inherently trusts the input.

During JSP page rendering, if the application encounters a <jato:form> tag, it evaluates the session state. The execution flow invokes getClientSession(), followed by hasAttributes(), getEncodedString(), isValid(), ensureAttributes(), and finally deserializeAttributes(). This sequence forces the application to decode and deserialize the state provided by the client.

Within com.iplanet.jato.ClientSession.java, the deserializeAttributes() method verifies that the encoded string is not null and passes it to Encoder.deserialize(). The Encoder.deserialize() function first decodes the Base64 representation via Encoder.decodeHttp64(). It then passes the raw bytes directly to standard Java deserialization mechanisms.

In the vulnerable implementation, Encoder.deserialize() instantiates an ApplicationObjectInputStream with the decoded byte array and immediately calls readObject(). The ApplicationObjectInputStream class does not implement any filtering or class whitelisting. Consequently, the JVM resolves and instantiates any class specified in the serialized payload, assuming the class exists within the application's classpath.

An examination of the source code reveals the precise mechanism of the vulnerability and the subsequent vendor remediation. The original code in com.iplanet.jato.util.Encoder relied on a native readObject() call without enforcing type safety.

The relevant code snippet before the patch demonstrates the insecure deserialization pattern:

// Vulnerable implementation in Encoder.java
public static Object deserialize(byte[] b, boolean compressed) {
    ByteArrayInputStream bais = new ByteArrayInputStream(b);
    ApplicationObjectInputStream ois = new ApplicationObjectInputStream(bais);
    return ois.readObject();
}

The vendor addressed this flaw in commit 014007c63cacc834cc795a89fac0e611aebc4a32. The patch removes the direct instantiation of ApplicationObjectInputStream. Instead, it delegates the deserialization process to a centralized utility method.

// Patched implementation in Encoder.java
public static Object deserialize(byte[] b, boolean compressed) {
    return IOUtils.deserialise(b, compressed);
}

The IOUtils.deserialise method enforces strict type constraints. It utilizes a WhitelistObjectInputStream that verifies incoming classes against an explicit whitelist of approximately 40 benign classes required for session state management. If an attacker attempts to inject classes such as PriorityQueue or TemplatesImpl, the stream throws an InvalidClassException and aborts the deserialization process.

Exploiting this vulnerability requires zero authentication and only network access to an exposed OpenAM instance. The attacker must target a JSP endpoint that utilizes the JATO framework, such as /openam/UI/PasswordReset. The payload is delivered via the jato.clientSession parameter using either an HTTP GET or POST request.

The attack relies on a gadget chain present within the OpenAM runtime environment. The entry point of the payload is java.util.PriorityQueue, which triggers an operation during its readObject() deserialization phase. The PriorityQueue reconstructs its internal data structure by calling heapify(), which in turn invokes the compare() method of a supplied comparator.

The comparator injected by the attacker is org.forgerock.openam.core.Column$ColumnComparator, a class bundled in openam-core.jar. This comparator evaluates object properties by utilizing reflection via PropertyUtils.getObjectPropertyValue(). The attacker constructs the payload such that the property evaluated maps to the getOutputProperties() method of the TemplatesImpl class.

The TemplatesImpl class is a well-known deserialization sink in Java XSLT processing. Invoking getOutputProperties() forces the instantiation of a Translet class defined by the attacker's embedded bytecode. The JVM loads this malicious bytecode, executes its static initialization block (<clinit>), and runs arbitrary operating system commands via java.lang.Runtime.getRuntime().exec().

The exploitation of CVE-2026-33439 results in unauthenticated Remote Code Execution. The attacker gains the ability to execute arbitrary commands with the privileges of the user running the OpenAM application server (commonly a service account or root). This grants full control over the authentication infrastructure.

The CVSS v4.0 base score for this vulnerability is 9.3, reflecting a critical severity level. The metrics AV:N/AC:L/AT:N/PR:N/UI:N indicate that the attack is performed over the network, requires low complexity, demands no authentication, and involves no user interaction. The high impact metrics (VC:H/VI:H/VA:H) demonstrate complete compromise of confidentiality, integrity, and availability.

The Exploit Prediction Scoring System (EPSS) currently assigns a score of 0.00101 (0.101%), placing it in the 27.88th percentile. While this initial score reflects low historical exploitation at the time of disclosure, the existence of public proof-of-concept details and the similarity to the heavily exploited CVE-2021-35464 suggest that weaponization by threat actors is highly probable.

The definitive remediation for CVE-2026-33439 is upgrading OpenIdentityPlatform OpenAM to version 16.0.6. This version contains the updated Encoder.java implementation that strictly enforces class whitelisting during deserialization. Administrators must deploy the updated WAR file and restart the application container to ensure the patch is active.

If immediate patching is unfeasible, administrators should implement strict Web Application Firewall (WAF) rules. The WAF must inspect HTTP GET and POST requests targeting OpenAM endpoints and block any request where the jato.clientSession parameter contains Base64-encoded Java serialized objects. Specifically, rules should match the rO0AB magic bytes string at the beginning of the parameter payload.

As a defense-in-depth measure, operators should configure Java Enhancement Proposal (JEP) 290 deserialization filters at the Java Virtual Machine level. Implementing a global filter ensures that even if application-level whitelists fail or are bypassed, the JVM will strictly reject the instantiation of known dangerous classes such as TemplatesImpl or PriorityQueue during any deserialization operation.