CVE-2026-105119 in OpenAM
Summary
by MITRE • 10/03/2026
OpenAM before 16.1.3 applies its OAuth2 Provider PKCE enforcement only to authorization requests whose response_type is exactly code, so codes issued through OpenID Connect hybrid flows (code token, code id_token, code token id_token) carry no bound challenge. An attacker who intercepts such a code can redeem it for a public client's tokens with any non-empty code_verifier.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability in ForgeRock Access Manager versions prior to 16.1.3 represents a critical implementation flaw within the OAuth2 and OpenID Connect protocol stack, specifically concerning the enforcement of Proof Key for Code Exchange PKCE mechanisms on public clients. The core technical deficiency lies in the conditional logic used by the authorization server when validating the code_verifier during the token exchange phase. While the system correctly enforces PKCE requirements for standard Authorization Code flows where the response_type parameter is strictly set to code, it fails to apply this same cryptographic binding check to hybrid flow responses. Hybrid flows are designed to return multiple types of credentials in a single request, such as an authorization code alongside access tokens or identity tokens, with common configurations including code token, code id_token, and code token id_token. In these scenarios, the server accepts the redemption request without verifying that the provided code_verifier matches the challenge sent during the initial authorization request, effectively rendering the PKCE protection inert for this specific subset of traffic.
This architectural oversight creates a significant security gap because it allows an attacker who intercepts or otherwise obtains an authorization code issued through these hybrid flows to redeem it using any arbitrary non-empty string as the code_verifier. Under normal secure operations, the server must cryptographically verify that the verifier corresponds to the challenge previously transmitted by the client during the initial flow initiation, thereby ensuring that only the legitimate application that initiated the login can complete the token exchange and obtain sensitive tokens like access or ID tokens. By bypassing this verification step for hybrid flows, an attacker who gains possession of a valid authorization code through any means, such as cross-site scripting attacks targeting public clients, URL leakage in logs or referrer headers, or network sniffing on unencrypted channels, can successfully exchange that code for active session tokens without possessing the original secret challenge.
The operational impact of this vulnerability is severe, particularly for applications utilizing OpenID Connect hybrid flows to authenticate users and obtain identity information while also requesting access scopes. Since public clients such as single-page applications or mobile apps cannot securely store client secrets, they rely entirely on PKCE to prevent authorization code interception attacks. The failure to enforce PKCE in these specific flow types means that the primary defense mechanism against token theft is completely nullified for a substantial portion of common authentication patterns. An attacker can leverage intercepted codes to impersonate legitimate users, gaining unauthorized access to protected resources and sensitive personal data contained within ID tokens or accessible via obtained access tokens. This undermines the integrity of the entire identity federation process and exposes organizations to account takeover attacks even when PKCE is ostensibly enabled in their configuration.
To mitigate this risk, administrators must upgrade ForgeRock Access Manager to version 16.1.3 or later where the code verification logic has been corrected to consistently apply PKCE checks across all response types including hybrid flows. Until an upgrade can be performed, organizations should consider disabling public client access for hybrid flow configurations if possible and enforcing strict redirect URI validation to minimize the attack surface for interception. Additionally, implementing additional layers of security such as mutual TLS or requiring private clients with secrets where feasible can provide compensating controls. This vulnerability is classified under CWE-347 Improper Verification of Cryptographic Signature which reflects the failure to properly validate cryptographic proofs during authentication exchanges and aligns with ATT&CK technique T1528 Steal Application Access Token, highlighting the risk of token theft through protocol manipulation flaws in identity providers.