Introduction
A flaw in Keycloak's handling of OpenID Connect client data during session restarts allows a low privilege user to force the issuance of access tokens through the implicit flow, even when administrators have explicitly disabled it. For organizations relying on Keycloak (or Red Hat Single Sign-On) as their identity backbone, this means access tokens can silently leak into server logs, proxy logs, and HTTP Referrer headers across the entire request path.
Keycloak is a widely deployed open source Identity and Access Management platform that provides authentication, user federation, identity brokering, and fine grained authorization for modern applications. Red Hat distributes a supported enterprise variant called Red Hat Single Sign-On, built on the Keycloak project, which is used across industries to secure workloads using OpenID Connect, OAuth 2.0, and SAML 2.0. The combined footprint of the community and enterprise editions makes any authentication bypass in Keycloak a concern with a broad blast radius.
Technical Information
Root Cause: External Control of Assumed Immutable Web Parameters
CVE-2026-7571 is classified under CWE-472: External Control of Assumed-Immutable Web Parameter. This weakness class describes scenarios where a web application assumes certain parameters (passed via hidden form fields, cookies, or URL parameters) are immutable because they were set server side, but fails to enforce that immutability on subsequent requests. When Keycloak processes client data during a session restart, it does not adequately validate that the client configuration parameters have not been tampered with. An attacker can modify these parameters to re-enable the implicit flow on a client where it has been administratively disabled.
Attack Flow
The exploitation of this vulnerability follows a specific sequence:
-
Prerequisite gathering: The attacker must be a low privilege authenticated user who has obtained valid user credentials and the client ID of a target OIDC client. Client IDs are frequently exposed in public client applications (e.g., in JavaScript source code or browser network traffic), so this is not a high bar.
-
Session restart manipulation: During a session restart event, the attacker intercepts and modifies the client data sent to Keycloak. Because Keycloak does not sufficiently verify that these parameters match the server side client configuration, the manipulated data is accepted.
-
Implicit flow activation: The tampered client data tricks Keycloak into processing the authentication request as if the implicit flow were enabled. The system issues an access token directly in the authorization response URL fragment or query string.
-
Token issuance and leakage: Once the access token is embedded in the URL, it propagates through multiple infrastructure layers without any additional attacker action.
Systemic Token Leakage Channels
The implicit flow, by design, places the access token in the URL. This is precisely why RFC 9700 (Best Current Practice for OAuth 2.0 Security) explicitly warns that the implicit grant is vulnerable to access token leakage and access token replay, and recommends that clients should not use the implicit grant or other response types issuing access tokens in the authorization response.
Once the token lands in the URL via this bypass, it is captured by at least three independent channels:
| Leakage Channel | Exposure Mechanism |
|---|---|
| Server Logs | Standard web server access logs record the full request URL, including query parameters containing the access token. |
| Proxy Logs | Reverse proxies, load balancers, and other intermediaries capture and log the complete URL with the token in the query string. |
| HTTP Referrer Headers | When a user navigates away from the page, the browser sends the Referer header containing the token laden URL to the next destination, potentially a third party site. |
As OWASP notes, simply using HTTPS does not resolve this class of exposure because the sensitive data is in the URL itself, not in the transport layer.
Why This Matters Beyond a Single Bypass
The compounding effect is what elevates this vulnerability. A single successful exploitation does not just yield one unauthorized token; it deposits that token across multiple logging and routing systems. Server logs are often retained for weeks or months, proxy logs may be aggregated into centralized SIEM platforms accessible to operations staff, and Referrer headers can transmit the token to entirely external domains. The token's effective exposure window extends far beyond its cryptographic lifetime.
Affected Systems and Versions
The NVD entry and Red Hat advisory for CVE-2026-7571 do not specify exact affected version ranges at this time. The vulnerability affects Keycloak deployments where OIDC clients have the implicit flow disabled as a security control. Red Hat Single Sign-On, which is based on the Keycloak community project, is also potentially affected. Organizations running any current version of Keycloak should treat their deployments as potentially vulnerable until Red Hat publishes explicit version guidance.
Threat Intelligence
As of May 19, 2026, there is no confirmed active exploitation of CVE-2026-7571 in the wild. The associated Red Hat Bugzilla ticket (Bug 2464263) carries a status of "NEW," indicating the issue is acknowledged but remediation is still in progress.
However, the underlying attack pattern is not theoretical. A separate security advisory for OpenOLAT (GHSA-v8vp-x4q4-2vch) documented an authentication bypass via forged JWT in the OIDC implicit flow. That advisory's recommended mitigation explicitly cited Keycloak as an example Identity Provider that should be configured to prevent the bypass. This cross vendor pattern confirms that threat actors are actively researching implicit flow weaknesses in OIDC implementations, and the techniques required to exploit CVE-2026-7571 align closely with known attack tradecraft.
Mitigation Strategies
Since no official patch is available at the time of writing, organizations should implement the following architectural and operational controls:
Migrate to Authorization Code Flow with PKCE. RFC 9700 recommends that clients use the authorization code grant type with Proof Key for Code Exchange (PKCE) using the S256 challenge method. This eliminates the implicit flow entirely and ensures tokens are never placed in URLs. This is the single most impactful mitigation.
Deploy restrictive Referrer Policy headers. Configure all applications and identity endpoints to return a strict Referrer-Policy header. Avoid policies like unsafe-url, which will leak potentially private information from HTTPS resource URLs to insecure origins. A policy of no-referrer or strict-origin-when-cross-origin prevents the browser from transmitting the full URL to third parties.
Sanitize logging infrastructure. Configure reverse proxies, load balancers, and application servers to redact or exclude sensitive query string parameters from access logs. This reduces the window of exposure if a token does end up in a URL. Pay particular attention to centralized log aggregation systems where tokens could persist and be accessible to a broad set of internal users.
Enforce server side validation of client parameters. Review Keycloak configurations and any custom extensions to ensure that all client supplied data is strictly validated server side during session transitions. Do not rely on the assumption that parameters set during initial client registration remain unmodified in subsequent requests.
References
- Red Hat Security Advisory for CVE-2026-7571
- Red Hat Bugzilla Bug 2464263
- CWE-472: External Control of Assumed-Immutable Web Parameter
- OWASP: Information Exposure Through Query Strings in URL
- RFC 9700: Best Current Practice for OAuth 2.0 Security
- MDN: Referrer-Policy Header
- Keycloak GitHub Repository
- Keycloak Official Site
- Red Hat Single Sign-On Extended Lifecycle Support
- OpenOLAT Advisory GHSA-v8vp-x4q4-2vch: Authentication Bypass via Forged JWT in OIDC Implicit Flow
