Red Hat Keycloak EUVD-2026-45176

Three concurrent prerequisites are required for exploitation: (1) the attacker must hold at least low-privilege access - likely a legitimately registered OAuth client or an authenticated presence within the Keycloak realm (PR:L from CVSS vector); (2) the attacker must be capable of intercepting a victim's authorization code in transit, for example via a network interception position, an open redirect misconfiguration in a registered redirect_uri allowing code exfiltration to an attacker-controlled endpoint, or a referrer header leak from a non-HTTPS redirect; and (3) a victim must actively initiate an OAuth 2.0 authorization code flow (UI:R from CVSS vector). Deployments that enforce PKCE for all clients prevent a foreign client from redeeming the intercepted code even if obtained. Exploitation is limited to the AC:H complexity class - it is not opportunistic or automatable against default-configured deployments without a secondary code-leakage vector already in place.

The CVSS 5.4 (Medium) base score reflects a technically achievable but non-trivial attack path. AV:N confirms the attack is network-delivered but AC:H is the critical moderating factor - the attacker must intercept an in-flight authorization code, which demands a privileged network position or a secondary code-leakage vector such as an open redirect in a registered redirect_uri, a referrer header exposure, or a browser history leak. PR:L indicates the attacker is not fully unauthenticated; they likely need a registered OAuth client or authenticated presence in the same Keycloak realm. UI:R means a victim must actively initiate an authorization flow, constraining mass exploitation. Despite the moderate score, C:H is significant: successful exploitation yields live access tokens scoped to the victim's identity, enabling full account takeover within the OAuth-protected resource server. No EPSS data was provided in the input, the CVE is not listed in the CISA KEV catalog, and no POC status is confirmed, so there is no active exploitation signal. Real-world priority scales with the sensitivity of resources protected by the affected Keycloak instance; environments already enforcing PKCE may be substantially mitigated.

An attacker who operates a registered OAuth client in the same Keycloak realm, or who holds a man-in-the-middle network position, observes a victim's authorization code as it transits an insecurely configured redirect_uri or referrer header. The attacker immediately submits the intercepted code to Keycloak's token endpoint using their own client_id and client_secret, and because the server does not verify that the code was issued to that specific client, it issues valid access tokens representing the victim's identity. No public exploit code has been identified at time of analysis, but the attack technique is well-documented in OAuth security literature and requires no novel tooling.