CVE-2026-4636: 
Java vulnerability analysis and mitigation

CVE-2026-4636 is a UMA (User-Managed Access) policy bypass vulnerability in Keycloak that allows an authenticated attacker with the uma_protection role to gain unauthorized permissions to resources owned by other users. The flaw was reported on March 23, 2026, publicly disclosed on April 2, 2026, and affects org.keycloak:keycloak-services versions prior to 26.5.7, as well as Red Hat build of Keycloak versions prior to 26.2.15 and 26.4.11. It carries a CVSS v3.1 base score of 8.1 (High) (Red Hat CVE, Github Advisory).

The root cause is classified as CWE-551 (Incorrect Behavior Order: Authorization Before Parsing and Canonicalization). The /realms/{realm}/authz/protection/uma-policy/{resourceId} endpoint validates resource ownership only for the resource ID specified in the URL path, but fails to validate ownership of additional resource IDs supplied in the resources array of the JSON request body. An attacker can therefore craft a policy creation request using their own resource ID in the URL path while embedding victim-owned resource IDs in the body, causing the server to grant the attacker permissions over those victim resources. Exploitation requires: an authenticated account with the uma_protection client role, authorization services enabled on the client, and at least one victim resource created with ownerManagedAccess: true (Red Hat Bugzilla, Github Advisory).

Successful exploitation allows an attacker to obtain a valid Requesting Party Token (RPT) granting access to victim-owned UMA-protected resources, resulting in high confidentiality and integrity impact with no availability impact. The attacker can read sensitive data protected by victim resources and perform unauthorized actions on those resources. The scope is limited to the affected Keycloak realm, but in multi-tenant or enterprise deployments this could expose sensitive user data across organizational boundaries (Red Hat CVE, Github Advisory).

1. Prerequisite Setup: Ensure access to a Keycloak instance with a client configured with authorizationServicesEnabled: true. Obtain credentials for an attacker account that has been assigned the uma_protection client role.
2. Identify Victim Resource: Determine the victim_resource_id of a UMA resource created by a victim user via POST /realms/{realm}/authz/protection/resource_set with ownerManagedAccess: true and at least one scope (e.g., view).
3. Create Attacker Resource: As the attacker, authenticate and obtain an access token, then create an attacker-owned UMA resource via POST /realms/{realm}/authz/protection/resource_set — note the returned attacker_resource_id.
4. Inject Victim Resource into Policy: As the attacker, send a POST request to /realms/{realm}/authz/protection/uma-policy/{attacker_resource_id} with the following JSON body, embedding the victim's resource ID alongside the attacker's:

{
  "name": "malicious-policy",
  "scopes": ["view"],
  "users": ["attacker"],
  "resources": ["{attacker_resource_id}", "{victim_resource_id}"]
}

5. Confirm Policy Creation: Observe that the server returns HTTP 200, confirming the policy was created despite including a victim-owned resource — the path-level ownership check passed, but the body resources were not validated.
6. Request RPT for Victim Resource: As the attacker, send a POST to /realms/{realm}/protocol/openid-connect/token with parameters: grant_type=urn:ietf:params:oauth:grant-type:uma-ticket, audience={client_id}, permission={victim_resource_id}#view.
7. Obtain Unauthorized Access: The server returns HTTP 200 with a valid RPT containing permissions for the victim's resource, which the attacker can now use to access protected data or perform actions on that resource (Red Hat Bugzilla).

• Network: Unexpected POST requests to /realms/{realm}/authz/protection/uma-policy/{resourceId} where the resources array in the request body contains resource IDs not owned by the requesting user; POST requests to /realms/{realm}/protocol/openid-connect/token with grant_type=urn:ietf:params:oauth:grant-type:uma-ticket and permission parameters referencing resources not owned by the token requester.
• Logs: Keycloak audit/event logs showing UMA policy creation events by a user referencing resource IDs belonging to other users; successful RPT issuance events for resources where the requesting user is not the owner and has no prior legitimate policy.
• Behavioral: A single user account with the uma_protection role creating UMA policies that reference an unusually large number of distinct resource IDs, especially those owned by other users; repeated token requests for victim-owned resources shortly after policy creation events.

Upgrade to the patched versions: Keycloak 26.5.7 (upstream) or Red Hat build of Keycloak 26.2.15 / 26.4.11 (Github Advisory, RHSA-2026:6475). Red Hat has released four errata advisories covering standalone packages and OpenShift container images: RHSA-2026:6475, RHSA-2026:6476, RHSA-2026:6477, and RHSA-2026:6478 (Red Hat CVE). As a temporary workaround pending patching, restrict the uma_protection role to only fully trusted users, and monitor or alert on UMA policy creation requests that reference resources not owned by the requesting user. Disabling authorization services on clients that do not require UMA also eliminates the attack surface.

The vulnerability was noted in social media posts on Bluesky and Mastodon shortly after disclosure, with general community awareness but no significant controversy or high-profile researcher commentary. Clever Cloud published a changelog entry noting the Keycloak 26.5.7 update that addresses this issue. No major media coverage or vendor statements beyond Red Hat's standard advisory process have been identified (Red Hat CVE).