CVE-2026-46498

OpenAM (Open Access Management) versions prior to 16.1.1 do not keep OAuth tokens in an OAuth-only namespace within the shared Core Token Store (CTS), and OAuthAdapter accepts a CTS row whose BLOB merely claims to be an OAuth token without binding the trusted CTS token type or verifying integrity — a user-controlled-key authorization bypass (CWE-639). An attacker who can place controlled JSON into CTS under a known token identifier, for example via Push Registration followed by an anonymous SNS callback in an enabled realm, can then present that identifier to the token store. The result is the ability to mint OAuth 2.0 bearer tokens and OpenID Connect ID tokens with a chosen subject, client, realm, and scope, effectively impersonating any user to applications and APIs that trust OpenAM-issued tokens; the flaw does not itself create an OpenAM SSO session or grant admin console access. Any self-hosted deployment running a version before 16.1.1 is affected, with the CTS-write prerequisite making realms that have Push Registration and anonymous SNS callbacks enabled the most directly exposed. The issue is fixed in 16.1.1; no public proof of concept is known and no exploitation in the wild has been reported.

What to do: Upgrade to OpenAM 16.1.1, which namespaces OAuth tokens and enforces CTS type binding and integrity checks. Until patched, disable or tightly restrict Push Registration and anonymous SNS callback endpoints in enabled realms, and limit principals able to write to the Core Token Store. Review CTS contents and issued-token logs for anomalous or attacker-chosen token identifiers and revoke any suspect bearer or ID tokens.