What happened
CVE-2026-9689 is a vulnerability in Keycloak's OpenID Connect (OIDC) redirect URI handling that can lead to HTTP parameter pollution during an authentication flow. The problem appears when a Keycloak client is configured with a broad or wildcard redirect URI and an attacker persuades a user to follow a specially constructed authorization link. Keycloak may accept a redirect URI that already contains OIDC response parameters such as code, state, iss, or session_state. After authentication succeeds, Keycloak appends its own legitimate response parameters, leaving duplicate names in the final callback URL.
Duplicate query parameters are not handled consistently by every application framework or HTTP library. One client may use the first value, another may use the last, and another may expose all values as an array. That difference is what turns the Keycloak behavior into a security issue. A vulnerable relying application that uses a first-value or otherwise unsafe parsing strategy may consume the attacker-controlled value rather than the value generated by Keycloak.
Red Hat assigned CVE-2026-9689 a CVSS 3.1 base score of 4.2, rated Medium, with the vector CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N. The score reflects that the issue is remotely reachable and does not require the attacker to already have an account, but exploitation depends on specific configuration and application behavior and requires the victim to interact with an attacker-controlled link. CISA's enrichment data also recorded no known exploitation at the time of its assessment and classified the technical impact as partial.
How the vulnerability works
OIDC authentication relies heavily on redirects. A client sends a user to an identity provider such as Keycloak, the user authenticates, and the identity provider redirects the browser back to a pre-approved callback address. That callback can contain security-sensitive values including an authorization code and a state value used to associate the response with the correct browser session.
A simplified legitimate callback might look like this:
https://app.example.com/callback?state=SERVER_VALUE&code=AUTHORIZATION_CODEWith the vulnerable behavior, an attacker can attempt to place an OIDC response parameter inside a redirect URI before Keycloak adds the real response. Conceptually, the resulting callback can contain the same parameter twice:
https://app.example.com/callback?state=ATTACKER_VALUE&state=SERVER_VALUE&code=AUTHORIZATION_CODEThe duplicate parameter alone does not guarantee compromise. The important question is how the client application interprets it. If the application takes the first state, code, iss, or similar value when Keycloak intended the later value to be authoritative, the attacker may be able to influence authentication processing. Red Hat's issue description identifies three important conditions: the client uses a wildcard redirect URI, the victim follows an attacker-crafted authorization URL, and the relying application uses a parameter parsing strategy that trusts an attacker-controlled duplicate value.
This is why CVE-2026-9689 is better understood as a configuration-dependent authentication weakness rather than a universal Keycloak account takeover. The vulnerable Keycloak behavior creates the polluted redirect, but the final impact depends on the surrounding application's redirect configuration and request parsing logic.
Affected versions and fixes
Keycloak's upstream tracking issue states that the vulnerable behavior affected all versions when the issue was reported. The fix changes redirect URI validation so that incoming redirect URIs containing reserved OIDC response parameters are rejected before Keycloak appends its own values. The upstream issue is associated with the 26.4.14, 26.6.5, and 26.7.0 release lines, and Keycloak 26.7.0 lists CVE-2026-9689 among its security fixes.
For Red Hat build of Keycloak, NVD's vendor-supplied affected-product information identifies corrected builds in the 26.4 and 26.6 branches, including 26.4.14 and 26.6.5 product lines. Organizations should follow the exact update guidance for the Keycloak distribution they operate rather than assuming that every downstream package uses the same version number.
Upgrading is the preferred remediation because it removes the underlying behavior in Keycloak. Configuration hardening should still be performed even after patching. Keycloak's administration guidance recommends redirect URI patterns that are as specific as possible and warns against using a full wildcard in production. OpenID Connect is built around pre-registered redirect destinations, and restrictive matching reduces the number of alternate callback values an attacker can attempt to introduce.
Why it matters for website owners
Keycloak is often placed in front of administrative portals, customer accounts, internal dashboards, APIs, and other applications where authentication is a critical security boundary. A weakness in the redirect stage can therefore affect much more than the identity server itself. The risk is especially relevant when teams have historically used permissive callback patterns to support multiple environments, dynamic paths, local development, or several front-end applications under one client registration.
Broad redirect rules are convenient, but they increase the amount of attacker-controlled input that can reach the post-authentication callback. They also make it harder to reason about which application paths are actually trusted. CVE-2026-9689 demonstrates how a seemingly small parsing difference can become important when authentication parameters are duplicated and different components disagree about which value wins.
Website owners should also avoid treating a successful Keycloak upgrade as proof that every related redirect risk has disappeared. A site may still contain ordinary open redirects, permissive callback endpoints, inconsistent proxy handling, or application code that parses duplicate query values unexpectedly. Those issues are separate from CVE-2026-9689 and may require application-level fixes.
What to check on your site
- Identify Keycloak-backed applications. Confirm which public websites, portals, admin interfaces, and APIs use Keycloak or Red Hat build of Keycloak for OIDC authentication.
- Confirm the deployed version. Compare the running Keycloak version or Red Hat package build with the vendor's corrected release for your branch. Do not rely only on the version configured in a deployment file if containers or packages may have been updated separately.
- Review every client's Valid Redirect URIs. Replace broad wildcard patterns with the narrowest practical callback paths. A production client should not normally need a full
*redirect rule. - Look for redirect URIs that contain query parameters. Pay particular attention to callback URLs that can carry
code,state,iss,session_state, or other authentication-related parameters before Keycloak constructs its response. - Test duplicate parameter handling. Determine whether the application framework uses the first value, last value, or all values when the same query parameter appears more than once. Authentication callbacks should reject ambiguous or duplicated security-sensitive parameters rather than silently choosing one.
- Check redirect behavior outside Keycloak. Review application endpoints that accept values such as
redirect,returnUrl,next,continue, orcallback. An unrelated open redirect can make authentication and phishing workflows easier to abuse. - Retest after changes. After upgrading Keycloak and tightening redirect URI configuration, verify that normal login, logout, account recovery, and application-to-application SSO flows still work as expected.
Practical hardening steps
The first priority is to install a fixed Keycloak release for the branch in use. Next, reduce redirect URI scope. For example, a rule such as:
https://app.example.com/*is broader than a callback-specific entry such as:
https://app.example.com/auth/callbackIf an application legitimately has several callback routes, register each required route explicitly where practical. Separate development, staging, and production clients can also reduce the pressure to create one permissive pattern that covers every environment.
Application code should validate the callback independently. Security-sensitive OIDC response parameters should be present in the expected form, duplicated values should be rejected, and the returned state value should be validated against the state created for the initiating browser session. These controls are useful even after the Keycloak patch because they reduce reliance on one component behaving perfectly.
Teams should also review reverse proxies, ingress controllers, and load balancers in front of Keycloak. Redirect and host handling can be influenced by proxy configuration, and inconsistencies between external and internal URLs can lead administrators to introduce overly broad redirect patterns as a workaround. Fixing the underlying URL and proxy configuration is safer than widening allowed callbacks.
Using Vulnify for follow-up checks
Vulnify can support the public-facing review around this issue, but it should not be presented as a substitute for inspecting Keycloak client configuration or application source code. The Redirect Checker can be used to examine externally reachable redirect behavior, while the Chain Checker can help map how a public URL moves through one or more redirects.
For a broader assessment, the Vulnerability Scanner can help identify exposed website risks that may exist alongside authentication weaknesses. These checks are most useful after the Keycloak version and redirect URI configuration have been reviewed directly. CVE-2026-9689 depends on identity-provider configuration and client parsing behavior, so a public-surface scan alone cannot prove that a Keycloak deployment is fully remediated.
Related reading
The open redirect guide is particularly relevant because restrictive redirect destinations are one of the most effective ways to reduce the attack surface around authentication callbacks. Cookie protections remain a separate control, but they are worth reviewing at the same time because Keycloak-backed applications often rely on browser sessions immediately before and after the redirect flow.
Conclusion
CVE-2026-9689 is a moderate-severity Keycloak vulnerability with a narrow but meaningful exploitation path. It does not mean that every Keycloak deployment is immediately exploitable. The attacker needs a permissive redirect URI configuration, user interaction, and a relying application that handles duplicate parameters unsafely. Those conditions make exploitation less straightforward, but they also make the issue easy to miss in environments where redirect rules were created years ago and rarely revisited.
The appropriate response is straightforward: update Keycloak to a corrected release, remove unnecessary wildcard redirect URIs, validate OIDC callback parameters strictly, and retest the complete login flow. Website owners should also review general redirect behavior around the application because the same design habit that creates overly broad Keycloak callbacks can expose ordinary open redirect weaknesses elsewhere.