Introduction
A flaw in how Keycloak handles OpenID Connect client data during session restarts lets a low-privilege user force Keycloak to issue 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 with OpenID Connect, OAuth 2.0, and SAML 2.0. The combined footprint of the community and enterprise editions gives any authentication bypass in Keycloak 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 covers cases where a web application assumes that certain parameters (passed through hidden form fields, cookies, or URL parameters) cannot change because the server set them, but does not enforce that on later requests. When Keycloak processes client data during a session restart, it does not adequately check whether the client configuration parameters have been tampered with. An attacker can modify these parameters to re-enable the implicit flow on a client where an administrator has disabled it.
Attack Flow
Exploitation follows this sequence:
-
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.
-
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, it accepts the manipulated data.
-
The tampered client data tricks Keycloak into processing the authentication request as if the implicit flow were enabled. Keycloak then issues an access token directly in the URL fragment or query string of the authorization response.
-
Once the access token is in the URL, it propagates through several infrastructure layers with no further action from the attacker.
Systemic Token Leakage Channels
The implicit flow puts the access token in the URL by design. That is why RFC 9700 (Best Current Practice for OAuth 2.0 Security) warns that the implicit grant is vulnerable to access token leakage and access token replay, and recommends that clients not use the implicit grant or any other response type that issues access tokens in the authorization response.
Once this bypass puts the token in the URL, at least three independent channels capture it:
| 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, HTTPS alone does not resolve this class of exposure, because the sensitive data sits in the URL itself rather than in the transport layer.
Why This Matters Beyond a Single Bypass
One successful exploitation leaves the unauthorized token in several logging and routing systems at once, and the exposure compounds from there. Server logs are often retained for weeks or months. Proxy logs may be aggregated into centralized SIEM platforms that operations staff can access, and Referrer headers can send the token to entirely external domains. The token's effective exposure window extends far beyond its cryptographic lifetime.
Affected Systems and Versions
At this time, neither the NVD entry nor the Red Hat advisory for CVE-2026-7571 specifies exact affected version ranges. 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, may also be 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) has a status of "NEW," which indicates the issue is acknowledged but remediation is still in progress.
The underlying attack pattern has already appeared elsewhere. 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 named Keycloak as an example of an 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. The techniques needed to exploit CVE-2026-7571 closely match known attack tradecraft.
Mitigation Strategies
No official patch is available at the time of writing, so organizations should put the following architectural and operational controls in place.
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) and the S256 challenge method. This removes the implicit flow entirely, so tokens are never placed in URLs. It is the most effective mitigation on this list.
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 stops the browser from sending 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 shortens the exposure window if a token does end up in a URL. Pay particular attention to centralized log aggregation systems, where tokens could persist and be readable by a broad set of internal users.
Enforce server-side validation of client parameters. Review Keycloak configurations and any custom extensions to make sure the server strictly validates all client-supplied data during session transitions. Do not assume that parameters set during initial client registration stay unmodified in later 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
