Keycloak CVE-2026-7504

Exploitation requires (1) a Keycloak client whose 'Valid Redirect URIs' field is configured with a wildcard '*' entry - wildcard redirect URIs are not Keycloak's default and are widely documented as an anti-pattern, (2) victim user interaction in the form of clicking an attacker-crafted authorization URL, and (3) a Java URI parser that omits userInfo when multiple '@' characters appear in the authority. Exploitation does NOT require authentication to Keycloak itself (PR:N), does NOT require local access (AV:N, AC:L), and works against any client meeting the wildcard precondition; it is limited by the need for UI:R (the victim must initiate or complete the OIDC redirect) and by the wildcard configuration requirement, which together substantially shrink the realistic attack surface relative to the raw 8.1 score.

CVSS 8.1 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N) reflects a network-reachable, unauthenticated flaw with low complexity that nevertheless requires user interaction, which is consistent with a phishing-style open redirect rather than a server takeover; the C:H/I:H rating is unusually high for a pure open redirect and likely captures downstream account-takeover risk when stolen authorization codes or tokens are leaked to the attacker host. No EPSS score, KEV listing, SSVC decision, or POC indicator was provided in the input, so real-world exploitation pressure cannot be quantified from the data at hand - the realistic risk is tightly bounded by the precondition that a deployed client be configured with a literal wildcard '*' in Valid Redirect URIs, which is a known anti-pattern but not a default. Treat this as a high-priority issue for any tenant that uses wildcard redirect URIs (especially confidential clients issuing authorization codes), and a lower priority where redirect URIs are explicitly enumerated.

An attacker identifies a Keycloak client at a target organization whose 'Valid Redirect URIs' contains a wildcard, then sends a phishing email or chat message containing an OIDC authorization URL whose redirect_uri uses a multi-'@' user-info trick (e.g., https://login.victim.com@@attacker.example/cb). The victim clicks, authenticates to the real Keycloak, and Keycloak issues a redirect carrying the authorization code or token fragment to attacker.example, allowing the attacker to exchange it for the victim's session. No public exploit was identified at time of analysis, though the parser-differential primitive is straightforward to reproduce.