CVE-2026-97846: Keycloak mTLS Authentication Bypass Vulnerability

CVE-2026-97846 Overview

Keycloak contains an authentication flaw in its Standard Token Exchange V2 feature that bypasses mutual TLS (mTLS) holder-of-key binding. The holder-of-key mechanism normally binds an issued token to the requesting client's digital certificate, preventing token replay by any party that does not possess the matching private key. The new Standard Token Exchange V2 flow skips this certificate verification. An attacker who obtains stolen client credentials can request a standard, unrestricted token that is not bound to the original client certificate. The flaw is categorized under [CWE-287: Improper Authentication].

Critical Impact
Attackers holding stolen client credentials can exchange them for tokens that bypass mTLS holder-of-key protections, defeating a core defense against token theft and replay.

Affected Products

Keycloak (versions implementing Standard Token Exchange V2)
Red Hat build of Keycloak
Red Hat Single Sign-On downstream distributions

Discovery Timeline

2026-09-25 - CVE CVE-2026-97846 published to NVD
2026-09-25 - Last updated in NVD database

Technical Details for CVE-2026-97846

Vulnerability Analysis

Keycloak's mTLS holder-of-key binding ties an OAuth 2.0 access token to the client certificate presented during the initial token request. Any subsequent use of that token must occur over a TLS connection presenting the same certificate thumbprint recorded in the token's cnf claim. This mechanism, defined in RFC 8705, is intended to make stolen bearer tokens unusable to third parties.

The Standard Token Exchange V2 feature allows a client to exchange one token for another under defined policies. In the vulnerable implementation, the token exchange endpoint does not propagate or re-validate the client certificate binding when issuing the new token. The resulting token lacks the cnf constraint or is issued without verifying the presenting certificate, converting a certificate-bound token into an unrestricted bearer token.

Root Cause

The root cause is missing certificate verification logic in the Standard Token Exchange V2 code path. The exchange flow treats client authentication as sufficient and does not enforce the mTLS binding policy that applies to directly issued tokens.

Attack Vector

An attacker must first obtain valid client credentials, for example through credential theft, leaked secrets, or compromise of a client application. With those credentials, the attacker invokes the Standard Token Exchange V2 endpoint to receive a new access token that is not bound to any client certificate. The attacker then presents the token to resource servers that would otherwise reject non-matching certificate holders, obtaining the confidentiality and integrity scope of the original principal.

No verified exploit code is published. Technical detail is available in the Red Hat CVE-2026-97846 Advisory and Red Hat Bug Report #2540949.

Detection Methods for CVE-2026-97846

Indicators of Compromise

Token exchange requests to the /protocol/openid-connect/token endpoint using grant_type=urn:ietf:params:oauth:grant-type:token-exchange from clients configured for mTLS holder-of-key.
Issued tokens that lack the expected cnf.x5t#S256 confirmation claim despite originating from an mTLS-bound client.
Access attempts to protected resources using tokens presented over TLS sessions with a certificate thumbprint that does not match the token's original binding.

Detection Strategies

Audit Keycloak event logs for TOKEN_EXCHANGE events correlated with clients that have tls-client-certificate-bound-access-tokens enabled.
Compare the certificate thumbprint on token-issuance TLS sessions against the thumbprint presented on subsequent resource access.
Flag any Standard Token Exchange V2 call whose output token is used from an IP address or workload distinct from the exchanging client.

Monitoring Recommendations

Enable Keycloak detailed event logging and forward authentication and token events to a centralized analytics platform.
Alert on first-time use of the Standard Token Exchange V2 grant by clients that have historically relied on direct mTLS token issuance.
Monitor for anomalous spikes in token exchange volume, especially from service accounts tied to high-value APIs.

How to Mitigate CVE-2026-97846

Immediate Actions Required

Disable the Standard Token Exchange V2 feature on realms where mTLS holder-of-key binding is a required control.
Rotate client secrets and credentials for any client authorized to perform token exchange.
Restrict the token-exchange permission in client policies to a minimal set of trusted internal services.

Patch Information

Consult the Red Hat CVE-2026-97846 Advisory for fixed Keycloak and Red Hat build of Keycloak versions. Apply the vendor-supplied update that enforces certificate binding validation within the Standard Token Exchange V2 flow. Track remediation status for downstream distributions through the Red Hat Bug Report #2540949.

Workarounds

Turn off the Standard Token Exchange V2 feature flag until the patched release is deployed.
Enforce client authentication using signed JWT or private key JWT in addition to mTLS to raise the bar for credential theft.
Apply resource server policies that validate the cnf.x5t#S256 claim and reject tokens missing the expected binding.

bash

# Disable Standard Token Exchange V2 at Keycloak startup
bin/kc.sh start --features-disabled=token-exchange-standard-v2

# Verify the feature state
bin/kc.sh show-config | grep -i token-exchange