CVE-2026-7571: Keycloak Auth Bypass Vulnerability

CVE-2026-7571 Overview

A flaw in Keycloak allows a low-privilege authenticated user to bypass a security control intended to disable the implicit flow in OpenID Connect (OIDC) clients. By manipulating client data during a session restart, an attacker with valid user credentials and knowledge of a client ID can obtain an access token that should not be issued. The resulting tokens can also leak into server logs, proxy logs, and HTTP Referer headers, producing sensitive information disclosure. The weakness is tracked as CWE-472: External Control of Assumed-Immutable Web Parameter. Red Hat has published advisories and shipped fixes for affected Keycloak builds.

Critical Impact

Authenticated attackers can mint OIDC access tokens through a disabled implicit flow and harvest those tokens from logs and Referer headers, enabling impersonation of users in downstream applications.

Affected Products

• Red Hat build of Keycloak (see RHSA-2026:19596)
• Red Hat Single Sign-On / Keycloak container images (see RHSA-2026:19597)
• Upstream Keycloak OIDC client implementations prior to the fixed release

Discovery Timeline

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

Technical Details for CVE-2026-7571

Vulnerability Analysis

Keycloak enforces a per-client setting that disables the OIDC implicit flow, preventing the authorization server from returning access tokens directly in front-channel responses. The vulnerability allows a low-privilege user who can authenticate and reach the authorization endpoint to bypass that control. During a session restart, the server trusts client-controlled parameters that should be treated as immutable, allowing the response type and flow selection to be coerced back into implicit mode. The server then issues an access token through the front channel even though the client configuration prohibits it. Once issued in this manner, the token travels through URL fragments and request chains where it can be captured.

Root Cause

The root cause is improper handling of assumed-immutable parameters during session restart, classified under CWE-472. Keycloak re-reads client-supplied values when restoring an authorization session instead of binding the flow type to the validated client configuration. An attacker with knowledge of the client ID and valid credentials supplies altered request data, and the server fails to re-validate that the implicit flow remains disabled. This trust boundary failure converts a configuration-level restriction into a parameter the attacker controls.

Attack Vector

Exploitation requires network access to the Keycloak authorization endpoint and authenticated user credentials, but no administrative privileges or user interaction beyond the attacker's own session. The attacker initiates an OIDC authorization request against a target client, triggers a session restart, and submits manipulated client parameters that re-enable the implicit response type. Keycloak then issues an access token in the redirect fragment. Because the token is emitted in URL components, it is logged by reverse proxies, web server access logs, and any downstream service that captures the HTTP Referer header, producing secondary disclosure paths. See the Red Hat CVE entry for vendor-confirmed technical details.

Detection Methods for CVE-2026-7571

Indicators of Compromise

• Authorization responses containing access_token= in URL fragments for clients where the implicit flow is configured as disabled.
• Keycloak audit events showing repeated RESTART_AUTHENTICATION actions immediately followed by token issuance to the same client.
• Reverse proxy or load balancer access logs containing OIDC access tokens in query strings or fragments.
• Outbound HTTP requests from user browsers carrying access tokens in the Referer header to third-party origins.

Detection Strategies

• Correlate Keycloak event logs for CODE_TO_TOKEN and implicit flow token issuance against the static client configuration to flag mismatches.
• Inspect HTTP access logs for OIDC response parameters appearing in URL components on clients where only the authorization code flow is permitted.
• Hunt for anomalous session restart sequences originating from a single low-privilege account against multiple client IDs.

Monitoring Recommendations

• Forward Keycloak server, proxy, and application logs to a centralized analytics platform and alert on access tokens appearing in URL or Referer fields.
• Track per-client token issuance counts and alert when clients with implicit flow disabled emit any implicit-style responses.
• Enable Keycloak event listener auditing for RESTART_AUTHENTICATION, LOGIN, and CODE_TO_TOKEN events and retain them for retrospective analysis.

How to Mitigate CVE-2026-7571

Immediate Actions Required

• Apply the Keycloak updates referenced in RHSA-2026:19596 and RHSA-2026:19597 to all realms and instances.
• Rotate client secrets and invalidate active user sessions for clients where implicit flow was configured as disabled.
• Scrub historical proxy, web server, and SIEM logs that may contain leaked access tokens and restrict access to those archives.
• Review downstream applications that may have accepted tokens issued through the bypass and revoke derived sessions.

Patch Information

Red Hat has released fixed packages through RHSA-2026:19596 and RHSA-2026:19597. Additional context is available in the Red Hat CVE page and Bugzilla 2464263. Administrators should upgrade to the fixed build, restart Keycloak instances, and verify that updated artifacts are loaded across all cluster nodes.

Workarounds

• Restrict access to the Keycloak authorization endpoint through network controls until patches are deployed.
• Enforce short access token lifetimes and require token binding or DPoP where supported to limit reuse of leaked tokens.
• Configure reverse proxies and web servers to strip OIDC response parameters from logged URLs and to suppress Referer headers on redirect chains.
• Audit all OIDC clients and confirm that only the authorization code flow with PKCE is enabled where implicit flow is not required.

# Configuration example: disable implicit flow and enforce code flow with PKCE
# Apply via kcadm.sh against each affected client
kcadm.sh update clients/$CLIENT_UUID -r $REALM \
  -s 'implicitFlowEnabled=false' \
  -s 'standardFlowEnabled=true' \
  -s 'attributes."pkce.code.challenge.method"=S256'