Red Hat Keycloak EUVD-2026-45222

Exploitation requires three concurrent conditions: (1) the attacker must already possess valid client credentials (client_id and client_secret) for a registered Keycloak client - PR:L in the CVSS vector confirms this authenticated prerequisite; (2) the target Keycloak realm must have Client Policies explicitly configured to enforce signed JWT client authentication (private_key_jwt or similar); realms that rely on default client_secret authentication are not affected because no stronger requirement exists to bypass; and (3) the attacker must be able to reach the Keycloak token endpoint over the network (AV:N/AC:L). Limiting factors include: without Client Policies configured, the vulnerability has no security impact; exploitation yields access equivalent to what the client credentials already permit, not privilege escalation to admin or other realms; and the scope is unchanged (S:U), meaning lateral movement to other systems is not a direct consequence.

The CVSS 3.1 score of 5.4 (Medium) with vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N accurately reflects the bounded nature of this vulnerability. Exploitation is network-accessible with low attack complexity, but PR:L confirms that valid client credentials are a hard prerequisite - an attacker who lacks any credential for the target realm cannot exploit this. The real-world risk is nuanced: the bypass is only meaningful to organizations that explicitly configured Client Policies to enforce signed JWT authentication, because without that policy in place, client_secret authentication is already permitted by default. Environments using Keycloak's default configuration are therefore not meaningfully exposed. For those that did harden their posture, this vulnerability silently voids that control. No EPSS data was provided in the source intelligence, no KEV listing exists, and no POC has been identified, suggesting exploitation remains theoretical or targeted rather than opportunistic. The 'Denial of Service' tag in the source data conflicts with A:N in the CVSS vector and is unsupported by the vulnerability description - treat it as a tagging artifact unless the vendor clarifies. Overall priority should be elevated for organizations with Client Policies actively configured, and treated as low urgency for all others.

An attacker who has obtained valid client credentials (client_id and client_secret) for a Keycloak client in a realm where Client Policies mandate signed JWT assertions constructs a token request containing a forged, unsigned assertion header designed to pass the policy compliance check. Keycloak's policy evaluator accepts the header at face value without verifying the cryptographic signature, classifies the requirement as met, and issues access tokens via the weaker client_secret grant - bypassing the administrator-configured security requirement entirely. No public POC has been identified, but the attack is mechanically straightforward for any developer familiar with OAuth 2.0 token endpoint parameters.