CVE-2026-9792: Keycloak Client Policies ROPC Grant Bypass

Technical summary

CVE-2026-9792 resides in the org.keycloak.protocol.oidc component and involves a logic flaw in Client Policies enforcement. The reject-ropc-grant executor, responsible for blocking ROPC token requests, is bypassed when specific condition providers (client-type, client-roles, client-attributes, client-scopes) are configured within a policy. This means that even though an administrator has explicitly set a policy rule to deny ROPC flows, the enforcement mechanism does not properly evaluate the condition, allowing ROPC grant requests to proceed. An unauthenticated remote attacker can interact directly with the OIDC endpoint to request tokens via ROPC, circumventing the intended security policy.

Business impact

Organizations relying on Client Policies to restrict authentication flows lose a key security boundary. If a company has disabled ROPC due to its inherent risks (credential exposure, token interception), this bypass re-introduces those risks. Attackers could obtain tokens to access protected resources, APIs, or other integrated services. The impact is information disclosure and unauthorized access; confidentiality and integrity are at risk, though availability is typically unaffected. For organizations with strict authentication policy requirements (regulated industries, zero-trust deployments), this represents a compliance violation that could require security incident notification.

Affected systems

Red Hat build of Keycloak is documented as affected. Organizations running Keycloak instances with Client Policies that use any of the four named condition providers (client-type, client-roles, client-attributes, or client-scopes) combined with a reject-ropc-grant executor are vulnerable. The vulnerability requires Keycloak to be configured as an OIDC authorization server and accessible over the network; it does not affect embedded or offline deployments. Verify the exact affected versions against Red Hat's advisory.

Exploitability

Exploitability is straightforward and requires no authentication. An attacker needs network access to the Keycloak OIDC endpoint and must craft a standard ROPC token request (username, password, client credentials). No user interaction is required, and the attack succeeds silently—the attacker receives a valid token even though policy should have rejected it. The CVSS score of 6.5 reflects this ease of exploitation, though the impact is limited to token acquisition rather than server compromise. This is a practical vulnerability that does not require sophisticated techniques or timing attacks.

Remediation

Apply the security patch from Red Hat for Keycloak when available—verify the patched version number in the official advisory. In the interim, if Client Policies cannot be immediately updated, consider operational mitigations: disable ROPC grant type entirely at the realm level if policy-based control is insufficient; restrict ROPC access to whitelisted clients via firewall or network segmentation; monitor token requests for ROPC grant type usage and alert on policy violations. Review any Client Policies currently configured with reject-ropc-grant to confirm they are functioning as intended post-remediation.

Patch guidance

Monitor Red Hat security advisories for Keycloak updates that address this bypass. When a patch is released, prioritize deployment to any Keycloak instances with Client Policies configured to restrict ROPC—these are the high-risk deployments. Test the patch in a non-production environment first to confirm the policy enforcer correctly rejects ROPC requests under all four condition provider scenarios (client-type, client-roles, client-attributes, client-scopes). After patching, re-validate that your security policies are being enforced as designed.

Detection guidance

Monitor Keycloak logs for token requests using the ROPC grant type, especially after a policy blocking ROPC should have applied. Check for successful token issuance when policies indicate ROPC should be denied. Enable OIDC protocol logging if available. Review Client Policies configurations to identify which ones use the vulnerable condition providers and executor combination. In network logs, look for POST requests to the OIDC token endpoint with grant_type=password originating from unexpected sources or clients.

Why prioritize this

Although CVSS is moderate (6.5) and the vulnerability is not yet in active exploitation databases, it enables a direct token-acquisition bypass that undermines authentication controls. Organizations with strict ROPC policies deserve visibility into whether this affects their deployments. Prioritize patching if you have Client Policies explicitly configured to block ROPC; deprioritize if ROPC is already disabled at the realm level or if Client Policies are not used.

Risk score, explained

The CVSS 3.1 score of 6.5 (MEDIUM) reflects: network-accessible attack vector (AV:N), low attack complexity (AC:L), no authentication required (PR:N), user interaction not needed (UI:N), scope unchanged (S:U), and limited impact—confidentiality and integrity are lowered (C:L, I:L) but availability is not affected (A:N). The score appropriately captures that this is a policy bypass rather than a critical system compromise, yet it enables unauthorized token acquisition.

Frequently asked questions