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