CVE-2026-62263 in OpenAM
Summary
by MITRE • 09/15/2026
Open Access Management (OpenAM) is an access management solution. Prior to 16.1.2, WebAuthnAuthentication.deserialize applies an ObjectInputFilter that allows every serialized object at depth greater than 1 and therefore constrains only an AuthenticatorImpl root object. A pre-authentication attacker can supply a userHandle whose serialized graph has a valid AuthenticatorImpl root and a nested gadget class, causing readObject or readResolve execution before the cast and assertion verification when a usable gadget is on the classpath. This bypasses the incomplete remediation for the earlier WebAuthn deserialization vulnerability. This issue is fixed in version 16.1.2.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The Open Access Management solution, commonly known as OpenAM, contains a critical security flaw within its Web Authentication (WebAuthn) implementation that allows for remote code execution through insecure Java object deserialization. Specifically, the vulnerability resides in the deserialize method of the WebAuthnAuthentication class, which is responsible for processing serialized data structures during the authentication handshake. Prior to version 16.1.2, this component implements an ObjectInputFilter designed to restrict the types of objects that can be instantiated from incoming serialized streams. However, the filter logic is flawed because it only applies strict constraints at a serialization depth greater than one while permitting any object type for the root element if it matches the expected AuthenticatorImpl class. This incomplete filtering strategy creates a significant bypass vector for attackers who understand Java deserialization mechanics and can construct malicious payloads that exploit this loophole.
A pre-authentication attacker with network access to the OpenAM server can leverage this vulnerability by crafting a specially crafted userHandle parameter within an authentication request. By supplying a serialized graph where the root object is a valid AuthenticatorImpl instance, the attacker satisfies the superficial check performed by the ObjectInputFilter. However, nested within this root object are gadget classes that were not adequately restricted because they reside at deeper levels in the serialization tree or are invoked through specific deserialization callbacks such as readObject or readResolve before the final cast and assertion verification steps can execute their security checks. If usable gadgets exist on the application classpath, these methods will be triggered during the unmarshalling process, allowing arbitrary code execution with the privileges of the OpenAM service account. This flaw effectively bypasses earlier remediation efforts that attempted to mitigate similar deserialization risks but failed to address this specific structural weakness in the filter configuration.
The operational impact of this vulnerability is severe, as it enables a remote attacker to execute arbitrary commands on the server hosting OpenAM without requiring valid user credentials or prior authentication. This represents a complete compromise of the access management infrastructure, potentially leading to unauthorized access to protected resources, data exfiltration, and further lateral movement within the internal network. The attack aligns with Common Weakness Enumeration (CWE) category CWE-502, which describes Deserialization of Untrusted Data, specifically highlighting cases where input validation is insufficient or bypassed through structural manipulation of serialized objects. Furthermore, this exploitation technique corresponds to MITRE ATT&CK tactic T1621, which covers Method Injection via Malicious Object Deserialization, illustrating how attackers can inject malicious logic into legitimate application flows by exploiting the automatic invocation of methods during object reconstruction.
To mitigate this risk, organizations running OpenAM must immediately upgrade to version 16.1.2 or later, where the deserialization filter has been corrected to properly constrain all levels of the serialized graph rather than just deeper nested objects relative to a permissive root check. In addition to patching, administrators should ensure that unnecessary gadget libraries are removed from the classpath if they are not required for business functionality, thereby reducing the attack surface available to potential exploiters. Implementing strict allow-lists for deserialization filters and monitoring logs for anomalous serialization patterns can provide additional layers of defense against similar attacks in other components or future versions.