CVE-2026-46623: OpenAM OAuth2 Module Account Takeover via Unverified Password Change
A logic flaw in OpenAM's OAuth2 authentication module silently resets any local user's password to their own username after an OAuth2 login, letting an unauthenticated attacker log in as that user usi
The problem
When an existing local account is matched during an OAuth2 re-login, the OpenAM OAuth2 module calls a user-update path that sets the local LDAP password to the literal value of the username string. No old-password verification, no random secret, no admin approval: the rewrite fires silently.
The default `ldapService` authentication chain then happily accepts that username as the password. Any account that has completed at least two OAuth2 logins (or one re-login for pre-existing accounts) is reachable over the normal REST authenticate endpoint with zero IdP interaction.
Successful exploitation gives the attacker a full SSO session carrying the victim's privileges.
Proof of concept
POST /openam/json/realms/root/authenticate HTTP/1.1
Host: openam.example.com
X-OpenAM-Username: jsmith
X-OpenAM-Password: jsmith
Content-Type: application/json
Accept-API-Version: resource=2.1
{}
# On success the server returns a tokenId (SSO session cookie value):
# {"tokenId":"AQIC5w...","successUrl":"/openam/console","realm":"/"}The root cause is in the OAuth2 module's account-update flow inside `OAuth.java`. When resolving an existing local identity the code called `setUserPassword(username)` unconditionally, using the username string as the new password value with no current-password check and no random generation (CWE-620 / CWE-1391).
Because OpenAM's minimum-password-length policy is enforced at the LDAP layer, only usernames shorter than the configured minimum are silently rejected, leaving all other accounts exposed.
The patch in 16.1.1 removes the unconditional password-rewrite call from the account-update path, so OAuth2 re-logins no longer touch the local credential at all. The companion fix also stops the update path from reactivating disabled accounts on every OAuth login.
The fix
Upgrade to OpenAM Community Edition 16.1.1 or later. If an immediate upgrade is not possible, disable the OAuth2 authentication module's account-creation/update feature in every affected realm, or restrict the `ldapService` chain so it is not reachable from untrusted networks while you plan the upgrade.
After upgrading, audit LDAP user records for accounts whose stored password hash matches their username and reset those passwords.