Bug 2450251 (CVE-2026-4636)

Summary: CVE-2026-4636 keycloak: Keycloak: UMA policy bypass allows authenticated users to gain unauthorized access to victim-owned resources.
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: aschwart, boliveir, mposolda, pjindal, rmartinc, security-response-team, ssilvert, sthorger, vmuzikar
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in Keycloak. An authenticated user with the uma_protection role can bypass User-Managed Access (UMA) policy validation. This allows the attacker to include resource identifiers owned by other users in a policy creation request, even if the URL path specifies an attacker-owned resource. Consequently, the attacker gains unauthorized permissions to victim-owned resources, enabling them to obtain a Requesting Party Token (RPT) and access sensitive information or perform unauthorized actions.
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Deadline: 2026-04-15   

Description OSIDB Bzimport 2026-03-23 08:51:36 UTC
The vulnerability is a UMA policy bypass in the
/realms/{realm}/authz/protection/uma-policy/{resourceId} endpoint. The
create-path validation only checks ownership for the resource ID in
the URL path, but the request body accepts a "resources" array that
can include additional resource IDs owned by other users. When the
policy is created, it grants the attacker permissions to all listed
resources, including victim-owned ones. The attacker can then request
an RPT (Requesting Party Token) for victim resources and receive valid
permissions.

*Requirements to exploit:* Authenticated user with uma_protection
role, victim must have created UMA-protected resources with
ownerManagedAccess enabled, authorization services enabled on the
client.

*Steps to reproduce:*

1. Deploy Keycloak with a client configured with
authorizationServicesEnabled:true
2. Create two users (attacker, victim) and assign both the
uma_protection client role
3. As victim, create a UMA resource via POST
/realms/{realm}/authz/protection/resource_set with
ownerManagedAccess:true and scopes:["view"] → note the
victim_resource_id
4. As attacker, obtain access token and create own UMA resource via
same endpoint → note the attacker_resource_id
5. As attacker, POST to
/realms/{realm}/authz/protection/uma-policy/{attacker_resource_id}
with body: {"name":"malicious-policy","scopes":["view"],"users":["attacker"],"resources":["{attacker_resource_id}","{victim_resource_id}"]}
6. Observe policy creation succeeds (HTTP 200) despite including
victim-owned resource
7. As attacker, POST to /realms/{realm}/protocol/openid-connect/token
with grant_type=urn:ietf:params:oauth:grant-type:uma-ticket,
audience={client_id}, permission={victim_resource_id}#view
8. Attacker receives valid RPT (HTTP 200) containing permissions for
victim resource, which was denied (HTTP 403) before the exploit