CVE-2026-16089: Keycloak Auth Bypass Vulnerability

CVE-2026-16089 Overview

CVE-2026-16089 affects the keycloak-services component of Red Hat Build of Keycloak. The vulnerability stems from OAuth 2.0 authorization codes that are not properly bound to the client that originally requested them. An attacker who intercepts an authorization code can modify the redemption request so that their own client exchanges it for an access token. This weakness enables account takeover scenarios where the attacker obtains tokens tied to a victim's identity. The flaw is classified under CWE-384: Session Fixation and impacts OAuth 2.0 authorization code flows served by Keycloak.

Critical Impact
Successful exploitation allows an attacker to obtain OAuth 2.0 access tokens bound to a victim's identity by redeeming an intercepted authorization code through an attacker-controlled client.

Affected Products

Red Hat Build of Keycloak
Keycloak keycloak-services component
OAuth 2.0 authorization code flow consumers of the affected Keycloak builds

Discovery Timeline

2026-07-17 - CVE-2026-16089 published to NVD
2026-07-22 - Last updated in NVD database

Technical Details for CVE-2026-16089

Vulnerability Analysis

The vulnerability resides in how the keycloak-services component validates OAuth 2.0 authorization codes during the token exchange step. In a correctly implemented authorization code flow, the code issued to a specific client_id must only be redeemable by that same client. Keycloak fails to enforce this binding, so a code issued for client A can be presented by client B and accepted.

An attacker who intercepts an authorization code, for example through a leaky Referer header, browser history, log exposure, or a compromised redirect endpoint, can substitute their own client_id in the token request. The Keycloak authorization server issues an access token tied to the victim's user session, granting the attacker access to protected resources under the victim's identity.

Exploitation requires user interaction and specific conditions to intercept the authorization code, which limits opportunistic abuse. Applications that log full URLs, use insecure redirect handling, or share codes across trust boundaries are most exposed. The issue does not require credentials for the victim account beyond the intercepted code.

Root Cause

The root cause is missing client binding validation on the authorization code redemption path. The token endpoint does not verify that the client_id presented in the token request matches the client_id recorded when the code was issued. This omission maps directly to CWE-384 and violates RFC 6749 Section 4.1.3, which mandates client authentication and binding for confidential clients.

Attack Vector

The attack is network-based and requires the attacker to obtain a valid authorization code intended for a legitimate client. Common interception paths include compromised third-party scripts, network eavesdropping on misconfigured TLS, and open redirect abuse. Once in possession of the code, the attacker calls the Keycloak /token endpoint using their own registered client, receives an access token, and impersonates the victim against downstream APIs. No verified public exploit or proof-of-concept code is available at this time. Refer to the Red Hat CVE-2026-16089 Advisory for authoritative technical details.

Detection Methods for CVE-2026-16089

Indicators of Compromise

Token requests to /realms/{realm}/protocol/openid-connect/token where the client_id differs from the client that initiated the corresponding /auth request for the same authorization code.
Multiple token redemption attempts for the same authorization code from different source IP addresses or user agents within a short window.
Unexpected access tokens issued to rarely used or newly registered clients tied to high-value user accounts.

Detection Strategies

Correlate Keycloak event logs by code_id and compare the client_id observed at CODE_TO_TOKEN events against the client_id observed at the preceding LOGIN event.
Enable Keycloak event listeners for CODE_TO_TOKEN_ERROR and successful CODE_TO_TOKEN events, then alert on mismatches or on tokens issued for clients that did not initiate the flow.
Monitor reverse proxy and application logs for authorization codes appearing in Referer headers or query strings outside of expected redirect URIs.

Monitoring Recommendations

Ingest Keycloak audit and admin events into a centralized SIEM and build detections keyed on client_id transitions across a single OAuth session.
Track baseline volumes of token issuance per client and alert on sudden spikes for low-traffic clients.
Review OAuth client registrations regularly and flag clients that request broad scopes but have limited legitimate usage.

How to Mitigate CVE-2026-16089

Immediate Actions Required

Apply the security update referenced in the Red Hat CVE-2026-16089 Advisory to all affected Keycloak deployments.
Rotate client secrets for confidential OAuth clients and revoke active sessions and refresh tokens issued during the exposure window.
Audit registered clients in each realm and remove or disable any client that is not actively required.

Patch Information

Red Hat has published guidance and fix information under the Red Hat CVE-2026-16089 Advisory and tracked the issue in Red Hat Bug Report #2501724. Administrators should upgrade to the Keycloak version identified in the advisory that enforces client binding on authorization code redemption.

Workarounds

Require Proof Key for Code Exchange (PKCE) with S256 for every client, including confidential clients, to bind authorization codes to the initiating session.
Enforce client authentication at the token endpoint using client_secret_jwt or private_key_jwt rather than client_secret_basic where possible.
Restrict redirect URIs to exact matches and disable wildcard patterns to reduce authorization code interception paths.

bash

# Enforce PKCE S256 on a Keycloak client using kcadm
kcadm.sh update clients/<CLIENT_UUID> -r <REALM> \
  -s 'attributes."pkce.code.challenge.method"=S256'

# Restrict redirect URIs to exact matches
kcadm.sh update clients/<CLIENT_UUID> -r <REALM> \
  -s 'redirectUris=["https://app.example.com/callback"]'