CVE-2025-8662

OpenAM 10.1.0 has an XXE (XML External Entity) vulnerability in the path /SSOPOST/metaAlias/%realm%/idpv2, allowing remote attackers to read arbitrary files via the SAMLRequest parameter.

In OpenAM 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 it implements DSAMECallbackInterface. Default configurations expose the endpoint without authentication, allowing attacker-controlled class initialization and unsafe deserialization to execute code in the server process. Enabling sunRemoteAuthSecurityEnabled does not prevent the vulnerable parsing because its check occurs later.

In OpenAM prior to 16.1.2, WebAuthnAuthentication.deserialize applies an ObjectInputFilter that allows every serialized object at depth greater than 1, constraining 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 cast and assertion verification. This bypasses the incomplete remediation for the earlier WebAuthn deserialization vulnerability.

In OpenAM prior to 16.1.1, AuthorizationCodeGrantTypeHandler requires a code_verifier only when the realm-wide codeVerifierEnforced setting is enabled, even when an authorization code stores a code_challenge. Because that setting is disabled by default, an attacker who intercepts a PKCE-protected authorization code can omit code_verifier and redeem the code. Public clients are directly affected, and confidential-client exploitation additionally requires client authentication material.

In OpenAM prior to 16.1.1, MSISDNValidation in the MSISDN authentication module concatenates the request-supplied MSISDN value into an LDAP search filter without escaping, while the default empty trusted-gateway list allows all traffic. In a realm where an MSISDN module is enabled in a reachable authentication chain, an unauthenticated remote attacker can inject LDAP filter metacharacters, select an arbitrary matching user, and obtain a normal authenticated OpenAM session without a password.

In OpenAM prior to 16.1.1, the Liberty Web Services SOAP receiver permits unauthenticated remote requests to write persistent entries through SOAPReceiver and DiscoveryService into a user's Liberty Discovery store and the shared root-realm Discovery branch. The server-side handlers bypass requester LDAP and identity ACLs, and the global path uses an internal administrative token. Deployments that consume Liberty discovery data can subsequently use manipulated service-routing or security-mechanism records.

In OpenAM prior to 16.1.1, WebAuthnAuthentication loads a serialized AuthenticatorImpl object graph from the configured userAttribute through loadAuthenticators without an ObjectInputFilter. Exploitation requires the WebAuthn flow to be reachable and an attacker to have previously written controlled data to that attribute through delegated administration, provisioning, directory access, legacy REST self-registration, or unsafe configuration. When those conditions hold, the data is deserialized before assertion verification and can execute a classpath gadget in the application server process.

OpenAM prior to 16.0.6 is vulnerable to pre-authentication Remote Code Execution (RCE) via unsafe Java deserialization of the jato.clientSession HTTP parameter, bypassing the WhitelistObjectInputStream mitigation applied to jato.pageSession after CVE-2021-35464.

OpenAM up to version 14.7.2 does not properly validate the signature of SAML responses in the SSO process, allowing attackers to impersonate any OpenAM user, including the administrator.

In OpenAM before 16.1.1, the RADIUS authentication module opens an unconnected datagram socket and trusts the first UDP datagram received on the client source port. The receive path does not verify the source IP and port, match the response identifier to the outstanding request, or verify the RFC 2865 Response Authenticator; the RFC 2869 Message-Authenticator is neither sent nor required. Any non-Reject/non-Challenge packet is treated as success, so an attacker can race the real server or spray forged Access-Accept packets and obtain a session for any RADIUS-mapped username without knowing the shared secret.