EUVD-2026-32708
GHSA-33j3-g875-37rp
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
1Blast Radius
ecosystem impact- 50 maven packages depend on org.keycloak:keycloak-services (22 direct, 28 indirect)
Ecosystem-wide dependent count for version 26.5.0.
DescriptionCVE.org
A flaw was found in Keycloak's Client Policies, specifically within the org.keycloak.protocol.oidc component. When certain condition providers (client-type, client-roles, client-attributes, client-scopes) are used to enforce security restrictions, the reject-ropc-grant executor is silently bypassed. This allows an unauthenticated remote attacker to obtain tokens via a Resource Owner Password Credentials (ROPC) grant, even when a policy is explicitly configured to block it. This bypass can lead to unauthorized access and information disclosure.
AnalysisAI
Policy enforcement bypass in Red Hat Build of Keycloak's Client Policies framework allows unauthenticated remote attackers to obtain OAuth2 tokens via the Resource Owner Password Credentials (ROPC) grant even when an explicit reject-ropc-grant executor is configured to block it. The bypass is triggered specifically when certain condition providers - client-type, client-roles, client-attributes, or client-scopes - are used within the same policy, causing silent executor skipping rather than a fail-closed enforcement error. Successful exploitation results in unauthorized token issuance and potential information disclosure. No public exploit code and no CISA KEV listing have been identified at time of analysis.
Technical ContextAI
Keycloak implements OAuth2/OIDC enforcement logic through a Client Policies framework within the org.keycloak.protocol.oidc package. Client Policies consist of conditions (criteria that determine when a policy applies) and executors (actions enforced when conditions match). The reject-ropc-grant executor is designed to block the Resource Owner Password Credentials flow - a legacy OAuth2 grant type where client applications collect usernames and passwords directly, considered high-risk in modern deployments. CWE-280 (Improper Handling of Insufficient Permissions or Privileges) identifies the root cause: the enforcement logic fails to properly propagate or evaluate privilege restrictions when specific condition provider types (client-type, client-roles, client-attributes, client-scopes) are evaluated, resulting in the executor being silently skipped rather than applied. The affected product is identified by CPE cpe:2.3:a:red_hat:red_hat_build_of_keycloak:*:*:*:*:*:*:*:* - the wildcard version suggests all currently available versions of Red Hat Build of Keycloak are potentially affected.
RemediationAI
No vendor-released patch version has been identified from the available data; the Red Hat CVE page (https://access.redhat.com/security/cve/CVE-2026-9792) and Bugzilla entry (https://bugzilla.redhat.com/show_bug.cgi?id=2482459) should be monitored for patch availability and exact fix versions. As an immediate compensating control, administrators should audit all Client Policies that use a reject-ropc-grant executor and verify whether those policies employ any of the four affected condition types: client-type, client-roles, client-attributes, or client-scopes. For policies using these conditions, a short-term mitigation is to disable the ROPC grant entirely at the realm level via Keycloak's realm settings (Realm Settings → Login → turn off 'Direct Access Grants Enabled'), which enforces the restriction at a layer above the bypassed executor - note this may break legacy integrations that rely on ROPC and should be tested in non-production environments first. Alternatively, temporarily replacing the affected condition providers with condition types not implicated in this bypass (e.g., client-access-type, if applicable to the deployment) may preserve partial policy enforcement. Do not rely solely on the reject-ropc-grant executor as the security boundary until a patched version is confirmed.
More in Red Hat Build Of Keycloak
View allAccount takeover in Red Hat Build of Keycloak allows an unauthenticated attacker to abuse the reset-credentials flow in
Account takeover in Keycloak (Red Hat build of Keycloak, Red Hat Single Sign-On 7) arises because the IdP-initiated SAML
Authentication bypass in Red Hat Build of Keycloak (and Red Hat Single Sign-On 7) lets an unauthenticated attacker forge
Privilege escalation in Red Hat Build of Keycloak's Dynamic Client Registration (DCR) grants an attacker with low-privil
Authorization bypass in the Keycloak Policy Enforcer allows any authenticated user to circumvent all enforced access con
URI normalization bypass in Keycloak's Authorization Services PathMatcher allows authenticated low-privilege users to re
Privilege escalation in Keycloak's Dynamic Client Registration (DCR) component allows attackers with standard user accou
Token exchange in Keycloak bypasses Google Workspace domain allowlist restrictions, enabling any valid Google account ho
Signature-verification bypass in Keycloak (and Red Hat's Keycloak-based products such as Red Hat Single Sign-On 7 and Re
Tenant-restriction bypass in Keycloak's Microsoft identity provider integration allows attackers holding any valid Micro
Session hijacking via SAML assertion replay in Keycloak's SAML broker component allows adjacent-network attackers to aut
Open redirect in Red Hat build of Keycloak permits remote attackers to send victims to attacker-controlled hosts by abus
Same technique Authentication Bypass
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today