Red Hat Keycloak CVE-2026-9792

Exploitation requires that the target Keycloak realm has at least one Client Policy explicitly configured with the reject-ropc-grant executor AND that the same policy uses one or more of the following condition providers: client-type, client-roles, client-attributes, or client-scopes. Without this specific combination, the bypass condition is not triggered. Realms where ROPC is blocked purely through realm-level settings (Direct Access Grants disabled) or through condition types outside the four affected providers are not exposed to this specific bypass. The CVSS vector (PR:N/UI:N) confirms no authentication or user interaction is required from the attacker's side - exploitation is unauthenticated and fully remote against default-network-accessible Keycloak token endpoints. The primary limiting factor is the non-default policy configuration requirement: operators who have not configured Client Policies with reject-ropc-grant are not affected by this bypass, though they may independently accept ROPC grant risk.

The CVSS 3.1 base score of 6.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N) reflects network-accessible, unauthenticated, low-complexity exploitation with limited confidentiality and integrity impact. The attack vector and no-authentication-required posture elevate practical risk: any network-reachable Keycloak instance with the specific policy configuration is exposed without requiring credentials or user interaction. However, impact is scoped (S:U) with only partial confidentiality and integrity compromise - this does not represent full account takeover in most architectures, but unauthorized token issuance can cascade into downstream resource access depending on token scope. No EPSS score was provided in the available data, preventing quantitative exploitation probability assessment. No CISA KEV listing and no public proof-of-concept exploit code have been identified, suggesting exploitation is not yet widespread. The real-world risk is moderate-to-elevated specifically for deployments that have invested in Client Policies to block ROPC - those operators believe they are protected but are not. Organizations that have never enabled the reject-ropc-grant executor are not exposed to this bypass, though they may already be accepting ROPC grant risk.

An attacker with knowledge of a valid client ID and user credentials - or access to a service account - targets a Keycloak realm where administrators believe ROPC is blocked by a Client Policy using the reject-ropc-grant executor combined with a client-roles or client-attributes condition. The attacker sends a standard OAuth2 token request to the /realms/{realm}/protocol/openid-connect/token endpoint using the password grant type; the condition evaluation causes the executor to be silently skipped, and Keycloak issues a valid access token contrary to the configured policy. The resulting token can be used to access downstream APIs or services scoped to that token.