EUVD-2026-39475
GHSA-gfv4-4vr2-rr4g
Severity by source
AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N
AC:H reflects the multi-condition configuration dependency (PERMISSIVE mode plus ownerManagedAccess plus absent type policy); PR:L confirms authenticated access required; no availability impact applies.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
1DescriptionCVE.org
A flaw was found in org.keycloak.authorization. An authenticated user with a granted User-Managed Access (UMA) permission ticket for one resource can exploit this by using a specific permission request prefix to bypass per-resource access control. This allows the user to gain unauthorized access to all resources of that type within the same resource server, even if they do not have a ticket for those specific resources. This vulnerability requires the resource server to be configured in PERMISSIVE policy enforcement mode and affects typed resources with ownerManagedAccess enabled, where no explicit policy protects the resource type. The primary consequence is unauthorized information disclosure or modification of resources.
AnalysisAI
Authorization bypass in Red Hat Build of Keycloak's UMA engine lets an authenticated user who holds a valid permission ticket for a single resource escalate access to all resources of the same type on the resource server by crafting a specific permission request prefix. The bypass is silently permitted when the resource server operates in PERMISSIVE enforcement mode with ownerManagedAccess enabled and no explicit type-level policy in place. No public exploit code exists and this CVE is not listed in CISA KEV at time of analysis, but the low attack complexity and network vector make this a credible internal-privilege escalation path in affected Keycloak deployments.
Technical ContextAI
The flaw resides in org.keycloak.authorization, the Keycloak module implementing User-Managed Access (UMA) 2.0 permission ticket flows. CWE-639 (Authorization Through User-Controlled Key) is the root cause class: the authorization engine uses attacker-supplied input - a typed permission request prefix - as part of the resource-matching logic without adequately scoping it to the specific ticket-granted resource. Because the resource server is in PERMISSIVE enforcement mode, unmatched or loosely-matched resources default to permitted rather than denied, allowing the prefix to function as a wildcard. The affected CPE is cpe:2.3:a:red_hat:red_hat_build_of_keycloak:*:*:*:*:*:*:*:* with no version upper or lower bound specified in available data. The vulnerability is conditional on three overlapping configuration states: PERMISSIVE enforcement mode, ownerManagedAccess enabled on the resource type, and the absence of an explicit policy protecting that resource type.
RemediationAI
No patched version has been identified in the available data - the CPE wildcard and absence of a fixed-version reference in either the Red Hat advisory (https://access.redhat.com/security/cve/CVE-2026-9799) or Bugzilla entry (https://bugzilla.redhat.com/show_bug.cgi?id=2482471) indicate patch availability should be confirmed directly with Red Hat before upgrading. As compensating controls: switch the affected resource server's policy enforcement mode from PERMISSIVE to ENFORCING - this eliminates the permissive fallback that enables the bypass, though it will deny access to any resource lacking an explicit policy, which may require policy auditing first. Alternatively, add explicit DENY policies at the resource type level to override the permissive default for sensitive types. Disabling ownerManagedAccess on resource types that do not strictly require user-delegated sharing also removes the attack surface entirely. Avoid relying on per-resource ticket scoping alone as an isolation boundary when operating in PERMISSIVE mode.
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