Red Hat Build Of Keycloak EUVD-2026-18213

Attacker must be an authenticated Keycloak user with the uma_protection role. No victim interaction required. Requires User-Managed Access (UMA) policy feature enabled. Remote network access. Affects Keycloak deployments using UMA resource authorization.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) indicates a network-exploitable vulnerability requiring low attack complexity and low-level authentication (PR:L), with no user interaction needed. The High confidentiality and integrity impact (C:H/I:H) combined with network accessibility makes this a serious access control bypass. However, the requirement for authenticated access with a specific role (uma_protection) significantly constrains the attack surface compared to unauthenticated vulnerabilities. The CISA KEV inclusion confirms this vulnerability is actively exploited in real-world environments, elevating it to critical priority for organizations running Keycloak. The scope unchanged (S:U) parameter indicates attacks remain within the vulnerable component's security context, somewhat limiting lateral movement potential. Real-world risk is HIGH for multi-tenant Keycloak deployments where multiple organizations or projects share a single instance, as attackers can cross tenant boundaries to access sensitive authentication and authorization data. Organizations should prioritize patching based on their deployment architecture, with shared/multi-tenant environments facing immediate risk and single-tenant deployments having slightly lower urgency.

An attacker who has compromised credentials for a low-privilege Keycloak user account with the uma_protection role authenticates to the target Keycloak instance. They identify resource identifiers belonging to high-value victim users through enumeration or social engineering. The attacker crafts a malicious UMA policy creation request that includes these victim resource identifiers in the request body while specifying their own resource in the URL path. Due to the authorization-before-parsing flaw, Keycloak validates the attacker's ownership of the URL-specified resource but fails to validate ownership of the body-embedded resource identifiers. The policy is created successfully, granting the attacker permissions to victim resources. The attacker then requests a Requesting Party Token (RPT) using the compromised policy, obtaining a valid OAuth token for accessing protected resources belonging to other users. With this RPT, the attacker can exfiltrate sensitive authentication data, modify victim user configurations, or gain access to downstream applications that trust Keycloak tokens, effectively achieving horizontal privilege escalation across the identity management infrastructure.