Keycloak CVE-2026-7504: Overview of Open Redirect via Wildcard URI Validation Bypass

Introduction

A parser mismatch between Keycloak and Java's URI implementation allows attackers to bypass redirect URI validation and send authenticated users to arbitrary destinations. For organizations relying on Keycloak as their identity provider, this flaw (scored CVSS 8.1) turns a common but discouraged configuration choice, using wildcard Valid Redirect URIs, into a concrete path for credential theft and phishing.

Technical Information

The root cause of CVE-2026-7504 lies in a disagreement between Keycloak's redirect URI validation logic and the underlying Java URI parser over how to handle the user-info component of a URL when it contains multiple @ characters.

The Parser Mismatch

In a standard URI, the user-info component appears before the @ symbol in the authority section (e.g., user@host). When a malicious redirect URL is constructed with multiple @ characters in the user-info section, Java's URI parser fails to properly extract the user-info. Instead of parsing the component correctly, it leaves only the raw authority field populated. This is the critical divergence: Keycloak expects the user-info to be available for its validation checks, but Java's parser silently drops it.

With the user-info absent from the parsed result, Keycloak's validation logic cannot detect the malformed input. The check that would normally catch the suspicious user-info content never fires. The system then falls back to a wildcard comparison against the configured Valid Redirect URIs. Because the client is configured with a wildcard (*), this fallback comparison succeeds, and Keycloak incorrectly permits the redirect to the attacker controlled destination.

Attack Flow

The exploitation path proceeds through these steps:

1. The attacker identifies a Keycloak client that has a wildcard (*) configured in its Valid Redirect URIs field.
2. The attacker constructs a malicious authorization request URL where the redirect_uri parameter contains multiple @ characters in the user-info section of the URI. This crafted URI points to an attacker controlled domain while appearing to reference a legitimate one.
3. The attacker delivers this crafted URL to a victim through a phishing email, a link on a compromised page, or another social engineering vector. User interaction is required; the victim must click the link or follow the malicious flow.
4. When Keycloak processes the authorization request, it attempts to validate the redirect URI. Java's URI parser fails to extract the user-info due to the multiple @ characters, leaving only the raw authority.
5. Keycloak's validation logic, unable to inspect the user-info, falls back to the wildcard comparison. The wildcard match succeeds.
6. The victim is redirected to the attacker controlled URL after authentication, potentially exposing authorization codes, tokens, or other sensitive information.

CVSS and Classification

The vulnerability carries a CVSS 3.1 base score of 8.1 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N. This reflects that the attack is network accessible, requires no privileges, has low attack complexity, but does require user interaction. Both confidentiality and integrity impacts are rated high, while availability is unaffected. The weakness is classified under CWE-601: URL Redirection to Untrusted Site ("Open Redirect").

Affected Systems and Versions

The vulnerability affects Keycloak deployments where clients are configured with a wildcard (*) in the Valid Redirect URIs field. The specific affected package identified in the Red Hat ecosystem is the Red Hat Build of Keycloak operator. Red Hat Single Sign On, which is based on the Keycloak community project, is also within scope.

Exact affected version ranges were not specified in the available advisory data. Organizations running any version of Keycloak with wildcard redirect URI configurations should treat their deployments as potentially vulnerable and apply the mitigation strategies described below.

Mitigation Strategies

The most effective immediate mitigation is to remove wildcard characters from the Valid Redirect URIs field for all clients within Keycloak. Red Hat recommends explicitly listing all allowed redirect URIs and ensuring that client applications are robust against open redirect vulnerabilities.

Keycloak provides built in features to enforce stricter validation:

• Secure redirect URIs enforcer client policy executor: Administrators should use this to restrict which redirect URIs clients can register and use.
• Exact string matching: The Keycloak upgrading documentation emphasizes that valid redirect URIs for clients should hold separate entries for each recognized URI, utilizing exact string matching rather than pattern based checks.

Implementing exact string matching provides the strongest defense against this validation bypass. Organizations should audit all Keycloak client configurations to identify any instances where wildcards are in use and replace them with fully qualified redirect URIs.

Threat Intelligence

As of the publication date, the available research data does not indicate that CVE-2026-7504 is being actively exploited in the wild. Neither the National Vulnerability Database nor the CVE record lists known threat actors or active campaigns leveraging this flaw.

That said, open redirects are highly valued by threat actors in practice. The OWASP Foundation documents how open redirects enable attackers to reroute users to untrusted URLs that may contain malware or compromise user systems. Academic research published at NDSS highlights that open redirects are frequently weaponized as enablers for phishing campaigns. In the specific context of an identity provider like Keycloak, an open redirect during an OAuth or OIDC flow is particularly dangerous because it can be used to intercept authorization codes or tokens issued after authentication.

Organizations should prioritize reviewing and testing redirect flows, especially in environments where wildcards were previously permitted in client configurations.

Vendor Security History

The Keycloak project maintains an active security posture with regular updates. Recent releases demonstrate a consistent cadence of addressing security flaws: version 26.5.6 (March 2026), version 26.5.7 (April 2026), and version 26.6.1 (April 2026) all included fixes for issues such as Server Side Request Forgery and improper access controls. Despite the vendor providing robust security features, the reliance on wildcard configurations remains a customer managed risk that requires administrative discipline.

References

• NVD: CVE-2026-7504
• CVE Record: CVE-2026-7504
• Red Hat Security Advisory: CVE-2026-7504
• Red Hat Bugzilla: Bug 2464128
• Red Hat Single Sign On Extended Lifecycle Support
• Keycloak Release Notes
• Keycloak Upgrading Guide
• Keycloak 26.5.6 Released
• Keycloak 26.5.7 Released
• Keycloak 26.6.1 Released
• OWASP: Open Redirect
• CWE-601: URL Redirection to Untrusted Site
• NDSS: Challenging the Myth of Harmless Open Redirection (PDF)