CVE-2026-97846: Keycloak-services: keycloak-services: standard token exchange v2 bypasses mtls holder-of-key binding

Published Sep 25, 2026
·
Updated

A vulnerability was found in Keycloak where the Standard Token Exchange V2 grant path fails to enforce mTLS holder-of-key token binding. When a confidential client is configured with tls.client.certificate.bound.access.tokens set to true, Keycloak correctly rejects standard token grants if no client certificate is provided. However, an attacker who possesses the client credentials and a valid subject token can use the Standard Token Exchange V2 endpoint to obtain an active Bearer access token without presenting a TLS client certificate. The resulting token lacks the cnf.x5t#S256 claim, effectively bypassing the configured sender-constraint and allowing unauthorized access to protected resources.

Other sources

Keycloak provides a feature called mTLS holder-of-key binding which ensures that a token can only be used by the client that originally requested it by binding it to their digital certificate. A flaw was discovered where the new Standard Token Exchange V2 feature does not check for this certificate. This allows an attacker with stolen client credentials to obtain a standard, unrestricted token that bypasses these security protections.

— MITRE

Affected Software

1 affected component
Red Hat Keycloak

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Enable tls.client.certificate.bound.access.tokens for confidential clients so standard token grants without a client certificate are rejected.

    Keycloak confidential client tls.client.certificate.bound.access.tokens = true

Event History

Sep 25, 2026
Data Sourced
via Red Hat·05:55 AM
DescriptionSeverityAffected Software
CVE Published
via MITRE·06:16 AM
Data Sourced
via MITRE·06:16 AM
DescriptionSeverityWeakness
Data Sourced
via NVD·07:16 AM
DescriptionSeverityWeakness

Frequently Asked Questions

1

Who is exposed to this issue?

Deployments using Keycloak mTLS holder-of-key binding are exposed if they also use the Standard Token Exchange V2 feature. An attacker must possess stolen client credentials to obtain an unrestricted token.

2

What does an attacker need to exploit the flaw?

The attacker needs valid client credentials that have been stolen. Exploitation does not require user interaction, but the attack complexity is rated high.

3

What is the impact of successful exploitation?

A successful attacker can exchange the stolen client credentials for a standard token that is not bound to the original client's certificate. This bypasses the intended mTLS holder-of-key protection and can affect confidentiality and integrity.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203