Red Hat Keycloak EUVD-2026-39475

All four of the following conditions must hold simultaneously: (1) the attacker is an authenticated user (PR:L) holding at least one legitimate UMA permission ticket for any resource on the target resource server; (2) the resource server is explicitly configured in PERMISSIVE policy enforcement mode - this is not the default hardened setting; (3) the target resource type has ownerManagedAccess enabled, allowing user-delegated access management; (4) no explicit policy exists at the resource type level - only per-resource policies are present, leaving the type unprotected under PERMISSIVE fallback. User interaction (UI:R per CVSS vector) is additionally required, meaning some user action must occur as part of the exploit flow. Exploitation is bounded to resources within the same resource server - cross-server escalation is not indicated. Deployments using ENFORCING or DISABLED enforcement mode, or those with explicit type-level policies, are not affected regardless of ownerManagedAccess status.

The official CVSS 4.6 (Medium) reflects the constrained impact profile: network-reachable (AV:N), low complexity (AC:L), requiring low privileges (PR:L) and user interaction (UI:R), with limited confidentiality and integrity impact only. No EPSS data was provided, and the CVE has neither a KEV listing nor known public exploit code, indicating no confirmed widespread exploitation. The real-world risk is tightly bounded by the deployment configuration: only resource servers simultaneously running in PERMISSIVE mode, with ownerManagedAccess on typed resources, and lacking type-level policies are exposed - this is a non-default combination that limits the attack surface. That said, PERMISSIVE mode is a documented operational choice, not a misconfiguration per se, and organizations relying on per-resource UMA tickets as their primary isolation boundary may be unknowingly vulnerable. The UI:R signal in the CVSS vector is noteworthy: it introduces a dependency on some user interaction that further limits opportunistic exploitation. The independent assessment raises AC to High given the multi-condition configuration dependency, which better reflects realistic exploitability.

An authenticated user who legitimately holds a UMA permission ticket scoped to a single resource (e.g., report:user-42) crafts a permission request using a type-scoped prefix (e.g., report:) that matches all resources of that type on the resource server. Because no explicit type-level policy exists and the server is in PERMISSIVE mode, Keycloak's authorization engine grants the request, allowing the attacker to read or modify all report-type resources belonging to other users within the same resource server. No public exploit code is known to exist, but the technique requires only standard UMA API calls.