CVE-2026-46498 in OpenAM
Summary
by MITRE • 09/15/2026
Open Access Management (OpenAM) is an access management solution. Prior to 16.1.1, OAuthTokenStore reads caller-supplied token identifiers from the shared Core Token Store (CTS) without an OAuth-only namespace, and OAuthAdapter accepts a row whose BLOB claims to contain an OAuth token without binding the trusted CTS type or verifying integrity. An attacker who can place controlled JSON in CTS under a known token identifier, such as through Push Registration followed by an anonymous SNS callback in an enabled realm, can mint OAuth bearer tokens and OpenID Connect ID tokens with chosen subject, client, realm, and scope. The flaw does not by itself create an OpenAM SSO session or grant console access. This issue is fixed in version 16.1.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified within Oracle Access Management, specifically affecting versions of OpenAM prior to release 16.1.1, represents a critical failure in the integrity verification and namespace isolation mechanisms governing OAuth token generation. This flaw stems from how the system handles data persistence and retrieval through its shared Core Token Store (CTS). The CTS serves as the underlying database for storing various types of tokens and session data within the OpenAM architecture. In vulnerable versions, the component responsible for retrieving OAuth tokens, known as OAuthTokenStore, fails to enforce strict namespace separation when reading caller-supplied token identifiers from this shared store. Instead of isolating OAuth-specific entries into a dedicated namespace that prevents collision or confusion with other data types, the system allows direct access based solely on the provided identifier without validating the context in which that identifier exists.
The technical root cause lies in the lack of binding between the trusted CTS type and the actual content retrieved by the OAuthAdapter component. When an application requests a token using a specific identifier, the adapter accepts any row from the database where the BLOB field claims to contain an OAuth token structure. Crucially, there is no verification step that confirms whether this data was legitimately generated by the system's own cryptographic processes or if it has been tampered with externally. The integrity of the stored object is not validated against a trusted source type marker, allowing arbitrary JSON structures placed into the database to be interpreted as valid OAuth bearer tokens and OpenID Connect ID tokens. This absence of strict typing and integrity checks effectively bypasses the security boundaries designed to protect token issuance logic from unauthorized manipulation.
An attacker with the ability to inject controlled JSON data into the Core Token Store under a known or predictable token identifier can exploit this flaw to mint fraudulent authentication artifacts. The exploitation path typically involves leveraging features such as Push Registration, which may allow anonymous callbacks via Simple Notification Service (SNS) in certain configurations. By manipulating these endpoints, an attacker can write malicious payloads directly into the CTS using specific keys that correspond to expected OAuth token formats. Once injected, when the system attempts to validate or use this data during authentication flows, it accepts the forged JSON as a legitimate token. This allows the creation of tokens with arbitrary subject claims, client identifiers, realm assignments, and scope permissions, effectively granting the attacker control over identity assertions without possessing valid credentials for those entities.
The operational impact of this vulnerability is significant in environments where OpenAM serves as an Identity Provider or acts within federated trust relationships. Although the flaw does not directly create a Single Sign-On session on the OpenAM console itself nor grant direct administrative access to the management interface, it enables severe identity fraud and privilege escalation at the application layer. Attackers can generate valid-looking tokens that are accepted by downstream relying parties trusting the OpenAM issuer. This facilitates unauthorized access to protected resources, data exfiltration, or lateral movement within a federated ecosystem where token validation relies on signature verification rather than session state checks against the central directory. The ability to choose subjects and scopes means an attacker can impersonate high-privilege users or expand their permissions beyond what was originally granted during initial authentication.
Mitigation strategies primarily involve upgrading to version 16.1.1 or later, where these namespace isolation and integrity verification mechanisms have been corrected. In the patched versions, OAuthTokenStore enforces strict separation of token types within the Core Token Store, ensuring that OAuth tokens are stored in a distinct namespace inaccessible by other components unless explicitly authorized through proper cryptographic channels. Additionally, the OAuthAdapter now validates the trusted type marker associated with each row before accepting it as an OAuth token, preventing arbitrary JSON injections from being interpreted as valid credentials. For organizations unable to immediately patch, implementing network-level controls to restrict access to SNS endpoints and reviewing Push Registration configurations for anonymous callback permissions can reduce the attack surface. Monitoring logs for unusual patterns in CTS writes or unexpected token generation events may also aid in early detection of exploitation attempts.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system fails to adequately validate and sanitize data received from external sources before processing it within critical security functions. It also relates closely to CWE-345 Insufficient Verification of Data Authenticity, since the application accepts data without verifying its origin or integrity against a trusted source. In terms of offensive cyber operations mapping, this flaw supports techniques associated with ATT&CK T1078 Valid Accounts and potentially T1606 Forged Identity Tokens, as it allows an adversary to create legitimate-looking credentials for unauthorized access. The exploitation method involving the injection of data into a shared store via callback mechanisms reflects common patterns seen in server-side request forgery or insecure direct object reference scenarios where trust boundaries are assumed rather than enforced through cryptographic means.