CVE-2026-37979: Keycloak Auth Bypass Vulnerability

CVE-2026-37979 Overview

CVE-2026-37979 is an access control flaw in Keycloak's OpenID Connect (OIDC) token introspection endpoint. The vulnerability allows a confidential client with valid credentials to bypass audience restrictions and retrieve sensitive token claims intended for other resource servers. This compromises the confidentiality of lightweight access tokens issued by the realm.

The weakness is categorized as Improper Access Control [CWE-284]. Any confidential client registered in the affected realm can exploit the issue remotely over the network. Red Hat distributes the fix through advisories RHSA-2026:19596 and RHSA-2026:19597.

Critical Impact

A confidential client with valid credentials can read access token claims scoped to other audiences, exposing sensitive data intended for different resource servers.

Affected Products

• Red Hat build of Keycloak (see RHSA-2026:19596 and RHSA-2026:19597 for affected versions)
• Keycloak realms exposing the OIDC token introspection endpoint
• Applications relying on audience claim restrictions for lightweight access tokens

Discovery Timeline

• 2026-05-19 - CVE-2026-37979 published to NVD
• 2026-05-20 - Last updated in NVD database

Technical Details for CVE-2026-37979

Vulnerability Analysis

Keycloak issues OIDC access tokens scoped to specific audiences. The aud claim identifies the resource servers that should accept a given token. The token introspection endpoint (/realms/{realm}/protocol/openid-connect/token/introspect) is intended to allow a resource server to validate tokens it received.

The flaw lies in how the endpoint enforces audience restrictions for lightweight access tokens. A confidential client authenticating to the introspection endpoint can submit a token issued for a different audience and receive the full claim set in response. Keycloak does not verify that the requesting client is among the intended audiences before returning the introspection payload.

This breaks a core trust assumption of OIDC: tokens minted for resource server A should not be readable by resource server B. The disclosed claims may include user identifiers, scopes, roles, and other metadata that downstream applications rely on for authorization decisions.

Root Cause

The root cause is missing audience-based access control on the introspection endpoint. The endpoint authenticates the calling client but does not check whether that client is listed in the target token's aud claim. This is an Improper Access Control weakness [CWE-284] in the authorization layer.

Attack Vector

An attacker must control a confidential client registered in the same realm and possess valid client credentials. The attacker obtains or intercepts a lightweight access token issued for a different audience. The attacker then calls the token introspection endpoint with that token and their own client credentials.

Keycloak responds with the decoded claim set, including user attributes and scopes intended only for the target resource server. The attacker can repeat this for any token they observe, harvesting confidential identity data across the realm.

No verified public proof-of-concept is published. See the Red Hat CVE Detail for CVE-2026-37979 for additional technical context.

Detection Methods for CVE-2026-37979

Indicators of Compromise

• Repeated calls to /realms/{realm}/protocol/openid-connect/token/introspect from a single confidential client using tokens issued for multiple distinct audiences.
• Introspection responses returning active: true for tokens whose aud claim does not match the calling client.
• Anomalous spikes in introspection traffic from clients that historically do not act as resource servers.

Detection Strategies

• Enable Keycloak event logging for INTROSPECT_TOKEN events and correlate the calling client_id against the introspected token's aud claim.
• Alert when a client introspects tokens it is not authorized to receive, treating audience mismatch as a high-severity signal.
• Review reverse proxy or API gateway logs in front of Keycloak for unusual POST request volumes to the introspection endpoint.

Monitoring Recommendations

• Forward Keycloak audit logs to a centralized SIEM and build detections around audience-to-client mismatches at the introspection endpoint.
• Baseline normal introspection patterns per client and alert on deviations in volume or token diversity.
• Monitor creation and credential rotation of confidential clients, since a compromised client is the prerequisite for exploitation.

How to Mitigate CVE-2026-37979

Immediate Actions Required

• Apply the Keycloak updates referenced in RHSA-2026:19596 and RHSA-2026:19597.
• Inventory all confidential clients in each realm and remove or disable any that are unused or untrusted.
• Rotate client secrets for any confidential client suspected of misuse.

Patch Information

Red Hat has published fixes through Red Hat Security Advisories RHSA-2026:19596 and RHSA-2026:19597. Refer to the Red Hat Bug Report #2455328 for tracking details and to the Red Hat CVE Detail for CVE-2026-37979 for the list of affected packages and fixed versions.

Workarounds

• Restrict which clients are permitted to call the token introspection endpoint by placing an authorizing reverse proxy in front of Keycloak.
• Avoid issuing lightweight access tokens in realms where untrusted confidential clients are registered until patches are applied.
• Reduce token claim sensitivity by minimizing user attributes and scopes embedded in access tokens.

# Configuration example - restrict introspection at a reverse proxy layer
# Example NGINX snippet limiting introspection to known resource server IPs
location /realms/myrealm/protocol/openid-connect/token/introspect {
    allow 10.0.10.0/24;   # resource server subnet
    deny  all;
    proxy_pass http://keycloak_upstream;
}