Ddos 
OpenAM, the widely-deployed open-source access management solution, is facing a critical security challenge following the discovery of a pre-authentication Remote Code Execution (RCE) vulnerability. The flaw, tracked as CVE-2026-33439, carries a CVSS score of 9.3 and essentially reopens a dangerous door that developers thought they had locked years ago.
The vulnerability targets OpenIdentityPlatform OpenAM 16.0.5 and potentially earlier versions. It allows an unauthenticated attacker to execute arbitrary OS commands as the application server user, leading to full server compromise, data exfiltration, and lateral movement within the network.
In 2021, a similar vulnerability (CVE-2021-35464) was discovered in the jato.pageSession parameter. At the time, developers mitigated the risk by introducing a WhitelistObjectInputStream to restrict deserialization to a list of approximately 40 safe classes.
However, the new research reveals that the JATO framework contains a second, overlooked deserialization entry point: the jato.clientSession HTTP parameter. Because this parameter was not included in the original whitelist mitigation, it remains “vulnerable to pre-authentication Remote Code Execution (RCE) via unsafe Java deserialization”.
To weaponize this flaw, an attacker sends a crafted, serialized Java object via a GET or POST request to any JATO ViewBean endpoint whose JSP renders <jato:form> tags. Common targets include Password Reset pages, which are typically accessible without any prior authentication.
The exploit leverages a complex “gadget chain” of classes already bundled within the OpenAM environment:
- Entry: PriorityQueue.readObject() triggers a comparison during a heapify operation.
- Pivot: The ColumnComparator.compare() function is used to invoke Method.invoke() on a TemplatesImpl object.
- Execution: This triggers the loading of attacker-supplied bytecode into the JVM via a TransletClassLoader, ultimately executing Runtime.getRuntime().exec().
Security teams running OpenAM are urged to take immediate action, as the flaw requires “no credentials or session tokens” to exploit.
Recommended Actions:
- Apply Whitelist Filtering: Administrators must apply WhitelistObjectInputStream filtering specifically to the ClientSession.deserializeAttributes() function to mirror the protection on page sessions.
- Audit Input: Perform a comprehensive audit of all callers of Encoder.deserialize() to ensure user-controlled input cannot reach unsafe deserialization sinks.
- Defense in Depth: Consider implementing a JVM-wide JEP 290 deserialization filter to provide a global safety net against future gadget chain discoveries.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.
Buy Me a Coffee
PayPal
