REDHAT-BUG-2540949: Medium severity Keycloak Keycloak vulnerability

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.

Affected Software

1 affected component
Keycloak Keycloak

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Configuration

    Set tls.client.certificate.bound.access.tokens to true so standard token grants without a client certificate are rejected and access tokens are bound to the client certificate.

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

Event History

Sep 25, 2026
Data Sourced
via Red Hat·05:55 AM
DescriptionSeverityAffected Software

Frequently Asked Questions

1

What does an attacker need to exploit this issue?

The attacker needs the confidential client's credentials and a valid subject token. They can then use the Standard Token Exchange V2 endpoint without presenting the TLS client certificate that the client configuration is intended to require.

2

Which deployments are affected?

Deployments using a confidential client with tls.client.certificate.bound.access.tokens set to true are affected when the Standard Token Exchange V2 grant path is available. The issue concerns token exchange rather than standard token grants, which correctly reject requests lacking a client certificate.

3

How can I tell whether exploitation may have occurred?

Look for Standard Token Exchange V2 requests made using the affected confidential client's credentials where no TLS client certificate was presented. A successful exploit produces an active Bearer access token that lacks the cnf.x5t#S256 claim.

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