CVE-2026-18211

CVE-2026-18211 is a redirect URI validation flaw in Keycloak's client policy executor. The vulnerability is straightforward: the check validates redirect URIs using string-prefix matching rather than proper URL parsing. It looks for 'https' at the start of a string instead of validating the actual hostname structure. This means an attacker can register a domain like `https-secure.attacker.com` and the policy will permit it because the string begins with 'https-' — even though the actual host is attacker-controlled. This is a classic string-comparison logic flaw masquerading as a security control. The check performs character matching where structural URI parsing is required. In OAuth/OIDC flows, a successful bypass lets attackers intercept authorization codes — high-value tokens that enable complete account takeover. The CVSS 5.4 score understates the impact because it evaluates the vulnerability in isolation, not in the context of Keycloak's architectural position: a single Keycloak instance often brokers authentication for hundreds of downstream applications. One successful intercept doesn't yield one compromised account; it yields the potential for credential stuffing across every application delegating identity to that realm. Audit your registered redirect URIs now. Search for any URI containing the pattern 'https-' where the portion after the hyphen is not a legitimate domain you control. This is prefix injection — the same pattern documented in OAuth security literature since the early 2010s. The bypass isn't a novel or clever attack; it's the natural consequence of using substring matching instead of URL parsing. Verify whether 'secure-client-uris' is your primary redirect URI enforcement or a supplementary control layered on top of existing validation. If it's the only enforcement in your deployment, the patch is necessary but insufficient — you need to reassess every client configuration approved under the assumption this control was functional. That assumption was false, and you now have false security debt to unwind. The unknown that matters: confirm whether this affects upstream Keycloak or only Red Hat's builds. If it's Red Hat-specific, the patch covers your exposure. If it exists upstream, you're looking at a core architectural gap in Keycloak's validation philosophy, not a one-off mistake — and other validation paths in the same component may have similar issues.

Reviewed through automated stages and approved by a human before publication.