Description

Open Access Management (OpenAM) is an access management solution. Prior to 16.1.2, the pre-authentication /authservice PLL endpoint accepts a CustomCallback XML element whose className value selects an arbitrary Java class for AuthXMLUtils to load and instantiate without verifying that it implements DSAMECallbackInterface. Default configurations expose the endpoint without authentication, allowing attacker-controlled class initialization and unsafe deserialization of a serialized Subject value to execute code in the server process. Enabling sunRemoteAuthSecurityEnabled does not prevent the vulnerable parsing and instantiation because its check occurs later. This issue is fixed in version 16.1.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-09-15T10:17:06.107Z",
  "pubdate": "2026-09-15T10:17:06.107Z",
  "executiveSummary": "Open Access Management (OpenAM) versions prior to 16.1.2 are vulnerable to a critical remote code execution (RCE) flaw arising from insecure deserialization and improper validation of user-supplied input.\nThe vulnerability resides in the pre-authentication /authservice PLL endpoint, which processes XML payloads containing CustomCallback elements.\nAn unauthenticated, remote attacker can exploit this by crafting a malicious XML payload that instructs the application to instantiate arbitrary Java classes.\nBecause the application fails to verify that these classes implement the expected DSAMECallbackInterface, the attacker can trigger unintended object initialization and perform unsafe deserialization of a serialized Subject value.\nThis behavior allows the execution of arbitrary code within the context of the server process, leading to full system compromise.\nThe vulnerability persists even if sunRemoteAuthSecurityEnabled is active, as the dangerous logic occurs prior to the security check validation.\nThis represents a high-risk security flaw that necessitates an immediate upgrade to version 16.1.2 or later to mitigate the potential for complete application takeover.",
  "technicalDetails": "The vulnerability is located within the /authservice PLL endpoint of the OpenAM access management solution. This endpoint is designed to process XML-based authentication requests through the AuthXMLUtils component. The root cause is a failure in input validation and type checking when handling the CustomCallback XML element.\nWhen a request is submitted to the endpoint, the application parses the incoming XML. The AuthXMLUtils component reads the className attribute within the CustomCallback element. Crucially, the application fails to validate that the specified class is restricted to an allowlist or that it implements the required DSAMECallbackInterface. Consequently, the application proceeds to instantiate the specified Java class using the attacker-controlled class name.\nThe attack flow begins with an unauthenticated attacker sending a crafted XML request to the /authservice endpoint. By specifying a malicious class name, the attacker forces the server to load and instantiate a class of their choosing. This instantiation process is compounded by the handling of a serialized Subject value associated with the authentication request. The application performs unsafe deserialization on this input, which can be leveraged to achieve arbitrary code execution. Because the system performs this instantiation and deserialization logic before the sunRemoteAuthSecurityEnabled flag is evaluated, the security mechanism is entirely bypassed.\nThe lack of authentication requirements for the /authservice endpoint significantly increases the attack surface, allowing any network-adjacent or remote entity to exploit the server. Once the malicious payload is processed, the attacker gains the ability to execute commands with the permissions of the user account running the OpenAM service.\nPost-exploitation, an attacker can achieve full control over the application environment, potentially leading to persistent access, data exfiltration, or the deployment of additional malware within the host server infrastructure. This flaw highlights the critical necessity of strict class verification when dynamic instantiation is employed in deserialization routines.\nAffected versions include all releases of OpenAM prior to 16.1.2. The issue was resolved in 16.1.2 by implementing rigorous validation of the CustomCallback className and ensuring that only permitted, compliant classes are allowed to be instantiated during the authentication process."
}