CVE-2026-46498: OpenAM Auth Bypass Vulnerability

CVE-2026-46498 Overview

Open Identity Platform OpenAM contains a broken access control flaw [CWE-639] that allows attackers to mint arbitrary OAuth bearer tokens and OpenID Connect ID tokens. The vulnerability affects OpenAM versions prior to 16.1.1. The OAuthTokenStore component reads caller-supplied token identifiers from the shared Core Token Store (CTS) without enforcing an OAuth-only namespace. The OAuthAdapter accepts rows 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 can forge tokens with a chosen subject, client, realm, and scope.

Critical Impact
Attackers can mint OAuth access tokens and OIDC ID tokens for arbitrary subjects and clients, enabling impersonation against downstream applications that trust OpenAM as an identity provider.

Affected Products

Open Identity Platform OpenAM versions prior to 16.1.1
OpenAM deployments with Push Registration enabled
OpenAM realms accepting anonymous SNS callbacks

Discovery Timeline

2026-09-15 - CVE-2026-46498 published to the National Vulnerability Database
2026-09-15 - Last updated in NVD database

Technical Details for CVE-2026-46498

Vulnerability Analysis

OpenAM stores session and token state in the Core Token Store (CTS), a shared persistence layer used by multiple subsystems. The OAuth token store trusts caller-supplied identifiers when reading CTS entries. It does not scope lookups to an OAuth-only namespace and does not verify that the retrieved row was originally written as an OAuth token type.

The OAuthAdapter deserializes a JSON BLOB from the CTS row and treats it as an authoritative OAuth token record. Because the adapter does not bind the trusted CTS type or validate integrity, any JSON placed under a known token identifier is accepted. This allows an attacker to control the subject, client identifier, realm, and scope claims embedded in the minted token.

The issue is classified as Authorization Bypass Through User-Controlled Key [CWE-639]. The flaw does not, by itself, create an OpenAM single sign-on session or grant administrative console access. The impact is confined to downstream relying parties that trust the forged bearer or ID tokens.

Root Cause

The root cause is a missing namespace isolation and type binding in the CTS-backed OAuth token retrieval path. OAuthTokenStore accepts arbitrary token identifiers without confirming the row originated as an OAuth entry. OAuthAdapter reconstructs the token from a BLOB without integrity checks, allowing controlled JSON to become a valid token record.

Attack Vector

An authenticated attacker with low privileges can trigger Push Registration in an enabled realm. The follow-on anonymous Simple Notification Service (SNS) callback allows the attacker to place controlled JSON in CTS under a predictable token identifier. The attacker then invokes standard OAuth or OIDC endpoints to retrieve a token minted from the attacker-controlled row. See the GitHub Security Advisory GHSA-cj8f-2fhf-826r for the disclosure details.

The upstream fix is contained in the OpenAM commit e047b01, which modifies OAuthAdapter.java and TokenIdFactory.java to enforce OAuth-only namespacing and type binding on CTS reads.

Detection Methods for CVE-2026-46498

Indicators of Compromise

Unexpected Push Registration flows initiated by low-privilege accounts in realms where push authentication is enabled
Anonymous SNS callback requests arriving at OpenAM endpoints from unexpected sources
OAuth access tokens or OIDC ID tokens issued for subjects, clients, or scopes that were never requested through a legitimate authorization flow
CTS entries whose BLOB contents describe OAuth tokens but were written through non-OAuth code paths

Detection Strategies

Correlate CTS write events from Push Registration and SNS callback paths with subsequent OAuth token issuance events sharing the same token identifier
Compare issued token subjects and client identifiers against active authorization grant records to identify tokens with no matching consent
Audit OIDC ID tokens for anomalous sub, aud, realm, or scope claim combinations that were not produced by a standard authorization endpoint

Monitoring Recommendations

Enable verbose audit logging for the OAuth2 provider, Push Registration service, and CTS operations in OpenAM
Forward OpenAM audit logs to a central analytics platform and alert on token issuance without a corresponding authorization request
Monitor downstream relying party applications for authentication events using bearer tokens whose subjects do not match legitimate user activity

How to Mitigate CVE-2026-46498

Immediate Actions Required

Upgrade all OpenAM instances to version 16.1.1 or later using the OpenAM 16.1.1 release
Revoke and reissue existing OAuth access tokens, refresh tokens, and OIDC ID tokens after patching to invalidate any forged tokens
Review Push Registration and SNS callback endpoint exposure and restrict access to trusted network segments where feasible
Audit relying party application logs for signs of token replay or impersonation prior to the patch date

Patch Information

The vendor released a fix in OpenAM 16.1.1. The corrective changes appear in openam-core/src/main/java/org/forgerock/openam/cts/adapters/OAuthAdapter.java and openam-core/src/main/java/org/forgerock/openam/cts/api/tokens/TokenIdFactory.java, which introduce OAuth-only namespacing and type binding for CTS reads.

The minimal patch metadata from the upstream commit is shown below.

java

// openam-core/src/main/java/org/forgerock/openam/cts/adapters/OAuthAdapter.java
 * Header, with the fields enclosed by brackets [] replaced by your own identifying
 * information: "Portions copyright [year] [name of copyright owner]".
 *
- * Portions Copyrighted 2025 3A Systems LLC.
+ * Portions Copyrighted 2025-2026 3A Systems LLC.
 */
package org.forgerock.openam.cts.adapters;