Unauthenticated remote code execution in OpenIdentityPlatform OpenAM through /authservice

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.

• The Maven package org.openidentityplatform.openam:openam-core in OpenIdentityPlatform OpenAM is affected for releases < 16.1.2; the vendor advisory describes the scope as all releases through and including 16.1.1.
• The release explicitly identified as patched is 16.1.2.
• The reviewed evidence does not independently establish the status of later or parallel release branches. An unverified branch should not be assumed to be unaffected.

OpenIdentityPlatform OpenAM processes XML requests at the PLL pre-authentication /authservice endpoint. The attacker-controlled className value in a CustomCallback element is used by AuthXMLUtils to load and instantiate an arbitrary Java class without verifying that the class implements DSAMECallbackInterface. In default configurations, the endpoint is reachable without authentication, so attacker-controlled XML can trigger class initialization in the server process.

The same processing path also deserializes a serialized Subject value without a safe class restriction. A suitably crafted value may therefore lead to code execution during deserialization in the OpenAM process. The sunRemoteAuthSecurityEnabled check occurs only after AuthXMLRequest.parseXML has parsed the request and instantiated the named class, so it does not stop the vulnerable processing path. The fix loads the named class without running static initializers, checks for DSAMECallbackInterface before instantiation, and applies an allowlist and limits to Subject deserialization. The available evidence does not identify a specific gadget chain or payload.

The vulnerability is reachable over the network through the PLL /authservice endpoint. In default configurations, an attacker does not need authentication or user interaction, and the supplied assessment describes the attack as having low complexity. The malicious request must contain attacker-controlled XML, including a CustomCallback element with an appropriate className value.

The supplied record marks public_exploit as false and known_exploited as null, but that does not establish that exploitation has not occurred. The public exploitation status is therefore not confirmed by the available evidence.

Successful exploitation lets an attacker execute code in the OpenAM process through externally selected Java class instantiation and unsafe Subject deserialization. Potential technical consequences include reading data, changing data or configuration available to the process, and disrupting service.

Because the endpoint can be reachable before authentication in default configurations, the impact is not limited to authenticated OpenAM users. Compromise of the process may undermine access-management functions that depend on the server. The actual post-exploitation reach depends on process privileges, network segmentation, and the secrets available to the server; the evidence does not establish a specific breach or exploit chain.

Successful exploitation can give an attacker control of the OpenAM server, which commonly supports an organisation's authentication and authorization flows.

• The attacker may execute code with the privileges of the OpenAM process, potentially reading accessible data, changing service data or configuration, and disrupting availability.
• If OpenAM supports multiple applications, compromise of the server may undermine the trustworthiness of login, authorization, or session decisions made by that service.
• Affected systems may require isolation, investigation, and review of credentials, sessions, or secrets accessible to the OpenAM process. These are plausible operational consequences, not evidence of a specific breach.
• The supplied record does not identify a victim, campaign, breach, or specific data that was accessed.

1. Upgrade OpenIdentityPlatform OpenAM to the vendor-identified patched release 16.1.2.
2. If an upgrade cannot be completed immediately, restrict or block external network access to /authservice. The advisory identifies this as the only reliable interim mitigation.
3. Consider blocking PLL requests containing <CustomCallback className="..."> at a reverse proxy or WAF, but first confirm actual traffic patterns to avoid disrupting legitimate custom callbacks.
4. Do not rely on sunRemoteAuthSecurityEnabled as a substitute for upgrading or restricting network access. Its token check occurs after the request has been parsed and the named class has been instantiated, so it does not prevent the vulnerable path.
5. After upgrading, verify that the running deployment contains the fixed code, that network controls cover the endpoint, and that systems awaiting remediation receive separate monitoring and containment.

1. Inventory all OpenAM deployments and verify the version of org.openidentityplatform.openam:openam-core, prioritizing systems that accept traffic from untrusted networks.
2. Check routing, reverse-proxy, and firewall policy to determine whether /authservice is reachable before authentication.
3. Review HTTP and application telemetry for unusual requests to /authservice, especially requests containing a CustomCallback element and a className attribute. This is a precautionary check, not a vendor-confirmed indicator of compromise.
4. Verify whether sunRemoteAuthSecurityEnabled is configured, but do not treat the setting as proof that the endpoint is safe or that the vulnerability is mitigated.
5. Review available application logs for unexpected class-initialization failures, XML parsing errors, and other anomalies following /authservice requests. No specific log event or IOC is supplied, and absence of such evidence does not prove that exploitation did not occur.