CVE-2026-9799: Authorization Bypass via UMA Permission Ticket Wildcard in Keycloak

Keycloak provides fine-grained authorization services modeled around OAuth 2.0 and the User-Managed Access (UMA) 2.0 specification. Within the org.keycloak.authorization subsystem, resource servers can delegate access control decisions to Keycloak, allowing both central administrators and individual resource owners to govern access to protected endpoints and data objects. Under UMA workflows, individual users can register and manage their own resources (ownerManagedAccess = true) and dynamically grant access to requesting parties via permission tickets.

CVE-2026-9799 is an authorization bypass vulnerability classified under CWE-639 (Authorization Bypass Through User-Controlled Key) within the DefaultPolicyEvaluator class located in the server-spi-private module. The flaw occurs during the evaluation of permission requests that utilize the resource-type-any:<type> selector prefix. This selector instructs the authorization engine to evaluate permissions across all resources registered under a specific resource type identifier rather than targeting a single resource instance ID.

When a Keycloak resource server is configured with PolicyEnforcementMode.PERMISSIVE, the policy evaluation engine defaults to granting access whenever an evaluated resource has no associated policies that explicitly deny the request. Because user-managed (UMA) resources rely on dynamic per-instance permission tickets rather than static administrative policies, evaluating unshared peer resources through a wildcard type query causes the evaluator to fall through to the permissive default-allow condition.

Consequently, an authenticated user who possesses a legitimate UMA permission grant for a single resource of a given type can issue an authorization request using resource-type-any:<type> and receive a Requesting Party Token (RPT) containing access permissions for every resource of that type on the resource server, bypassing the requirement for resource owner consent.

In Keycloak's authorization architecture, DefaultPolicyEvaluator.evaluate(...) orchestrates the evaluation of policies attached to a requested ResourcePermission. A resource server can operate in one of three enforcement modes: ENFORCING (the default mode, which denies access unless an explicit policy grants it), PERMISSIVE (which grants access if no matching policy denies it), and DISABLED (which skips policy evaluation entirely).

When resources are created with ownerManagedAccess = true, access governance is intended to be handled dynamically via PermissionTicketRepresentation objects approved by the resource owner. In typical UMA deployments, static administrative policies are not attached directly to individual user-owned resources or to their overarching resource type definitions. Instead, during authorization evaluation, Keycloak retrieves existing granted tickets associated with the requesting user and evaluates them alongside any applicable server-level policies.

The root cause of CVE-2026-9799 lies in how DefaultPolicyEvaluator handles batch evaluations triggered by the resource-type-any:<type> permission syntax when PolicyEnforcementMode.PERMISSIVE is active. When a client submits an authorization request specifying resource-type-any:<type>, Keycloak resolves all resource instances matching <type> and passes each resource as a ResourcePermission into DefaultPolicyEvaluator.evaluate(...).

For the specific resource where the user holds a valid UMA ticket, evaluation succeeds legitimately. However, as the evaluator iterates over peer resources owned by other users where the requester holds no ticket—and where no static policy is attached to the resource or resource type—zero policies are evaluated. Execution then reaches the fallback check at the end of evaluate(...): if (PolicyEnforcementMode.PERMISSIVE.equals(enforcementMode)). Because the evaluator failed to verify whether the target resource was governed by owner-managed access before invoking grantAndComplete(...), it treated the absence of static policies as an implicit approval, appending the unauthorized resource to the resulting RPT.

The vulnerability resides in server-spi-private/src/main/java/org/keycloak/authorization/policy/evaluation/DefaultPolicyEvaluator.java. Prior to the patch, the evaluate method checked for attached policies across the resource, its scopes, and its resource type. If no policies were evaluated (meaning the internal evaluation counter remained zero), the method checked if the resource server was operating in PERMISSIVE mode and immediately invoked grantAndComplete(...).

Commit bdb4db353a8b6042eac14ec26e1857138234bfd2 resolves this flaw by inspecting the ownerManagedAccess property of the target Resource before allowing the permissive fallback grant to execute, while also removing unused store factory variable declarations.

File: server-spi-private/src/main/java/org/keycloak/authorization/policy/evaluation/DefaultPolicyEvaluator.java
@@ -44,10 +44,6 @@ public class DefaultPolicyEvaluator implements PolicyEvaluator {
 
     @Override
     public void evaluate(ResourcePermission permission, AuthorizationProvider authorizationProvider, EvaluationContext executionContext, Decision decision, Map<Policy, Map<Object, Decision.Effect>> decisionCache) {
-        StoreFactory storeFactory = authorizationProvider.getStoreFactory();
-        PolicyStore policyStore = storeFactory.getPolicyStore();
-        ResourceStore resourceStore = storeFactory.getResourceStore();
-
         ResourceServer resourceServer = permission.getResourceServer();
         PolicyEnforcementMode enforcementMode = resourceServer.getPolicyEnforcementMode();
 
@@ -79,6 +75,9 @@ public void evaluate(ResourcePermission permission, AuthorizationProvider author
         }
 
         if (PolicyEnforcementMode.PERMISSIVE.equals(enforcementMode)) {
+            if (resource != null && resource.isOwnerManagedAccess()) {
+                return;
+            }
             grantAndComplete(permission, authorizationProvider, executionContext, decision);
         }
     }

The annotated post-patch logic in DefaultPolicyEvaluator.java functions as follows:

// After checking resource, type, and scope policies, if no policies matched:
if (PolicyEnforcementMode.PERMISSIVE.equals(enforcementMode)) {
    // FIX: Prevent owner-managed (UMA) resources from defaulting to 'grant'
    // when no static policies are attached during PERMISSIVE mode evaluation.
    if (resource != null && resource.isOwnerManagedAccess()) {
        return;
    }
    grantAndComplete(permission, authorizationProvider, executionContext, decision);
}

Fix Completeness Assessment

The fix directly addresses the logical inconsistency between PolicyEnforcementMode.PERMISSIVE and UMA resource semantics. By returning early when resource.isOwnerManagedAccess() evaluates to true, the evaluator ensures that user-managed resources always require an explicit positive decision (such as a granted UMA permission ticket or an explicit policy) regardless of whether the resource is queried directly by ID or indirectly through a resource-type-any:<type> wildcard selector. This closes the bypass vector without altering the expected behavior of PERMISSIVE mode for standard, non-UMA server resources.

Exploiting CVE-2026-9799 requires a specific combination of server configuration and initial user state. First, the target Keycloak client (resource server) must be configured with PolicyEnforcementMode.PERMISSIVE. Second, the target resources must share a common type attribute (e.g., patient-data) and have ownerManagedAccess set to true. Third, no explicit static policy can be bound to the resource type itself. Finally, the attacker must be an authenticated user who has obtained at least one valid, owner-approved UMA permission ticket for any single resource of that target type.

Once these prerequisites are satisfied, the attacker sends an OAuth 2.0 token request to Keycloak's token endpoint (/realms/{realm}/protocol/openid-connect/token) using the UMA grant type (urn:ietf:params:oauth:grant-type:uma-ticket). Instead of requesting permissions for the specific resource ID they were granted access to, the attacker supplies the permission parameter formatted as resource-type-any:<type>#<scope>.

The upstream test case added in UserManagedPermissionServiceTest.java demonstrates the exact reproduction sequence:

@Test
public void testResourceTypeAnyDoesNotLeakOwnerManagedResources() {
    // 1. User 'alice' creates an owner-managed resource of type 'patient-data'
    ResourceRepresentation aliceResource = new ResourceRepresentation();
    aliceResource.setName("alice-medical-records");
    aliceResource.setType("patient-data");
    aliceResource.setOwnerManagedAccess(true);
    aliceResource.addScope("read", "write");
    aliceResource = getAuthzClient().protection("alice", "password").resource().create(aliceResource);
 
    // 2. User 'marta' creates an unshared owner-managed resource of the same type
    ResourceRepresentation martaResource = new ResourceRepresentation();
    martaResource.setName("marta-medical-records");
    martaResource.setType("patient-data");
    martaResource.setOwner("marta");
    martaResource.setOwnerManagedAccess(true);
    martaResource.addScope("read", "write");
    martaResource = getAuthzClient().protection("marta", "password").resource().create(martaResource);
 
    // 3. User 'kolo' requests and receives an approved UMA ticket ONLY for Alice's resource
    PermissionResponse ticketResponse = getAuthzClient().protection()
            .permission().create(new PermissionRequest(aliceResource.getId(), "read"));
    AuthorizationRequest koloRequest = new AuthorizationRequest();
    koloRequest.setTicket(ticketResponse.getTicket());
    koloRequest.setSubmitRequest(true);
 
    List<PermissionTicketRepresentation> tickets = getAuthzClient().protection()
            .permission().findByResource(aliceResource.getId());
    PermissionTicketRepresentation aliceTicket = tickets.get(0);
    aliceTicket.setGranted(true);
    getAuthzClient().protection().permission().update(aliceTicket);
 
    // 4. Resource server operates in PERMISSIVE enforcement mode
    ResourceServerRepresentation settings = authzAdmin.getSettings();
    settings.setPolicyEnforcementMode(PolicyEnforcementMode.PERMISSIVE);
    authzAdmin.update(settings);
 
    // 5. 'kolo' requests an RPT using the 'resource-type-any:patient-data' selector
    AuthorizationRequest request = new AuthorizationRequest();
    request.addPermission("resource-type-any:patient-data", "read");
 
    AuthorizationResponse response = getAuthzClient().authorization("kolo", "password").authorize(request);
    AccessToken rpt = toAccessToken(response.getToken());
    Collection<Permission> permissions = rpt.getAuthorization().getPermissions();
 
    // On vulnerable versions, 'permissions' contains both 'alice-medical-records' and 'marta-medical-records'.
    // On patched versions, 'permissions' contains only 'alice-medical-records' (size == 1).
}

When executed against an unpatched Keycloak instance, the returned Requesting Party Token (RPT) includes signed permission claims for both alice-medical-records and marta-medical-records. The attacker can then present this RPT to the downstream resource server to read or modify Marta's protected resources depending on the requested scopes.

The primary impact of CVE-2026-9799 is unauthorized cross-user access to protected resources managed within a single Keycloak resource server. An attacker who satisfies the prerequisites can read and potentially modify confidential data owned by other users of the same application, depending on the scopes defined on the resource type (such as read or write).

The vulnerability is assigned a CVSS v3.1 score of 4.6 (Medium) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N. The Attack Vector is Network (AV:N) and Attack Complexity is Low (AC:L), as invoking the token endpoint with the resource-type-any: syntax requires no special timing or race conditions once the server configuration is in place. Privileges Required is Low (PR:L) because the attacker must be an authenticated user, and User Interaction is Required (UI:R) because a legitimate resource owner must first approve an initial UMA permission ticket for at least one resource of the target type.

Confidentiality and Integrity impacts are both rated Low (C:L/I:L) with Availability rated None (A:N). The overall scope remains Unchanged (S:U), and the impact is bounded by the non-default configuration requirement (PolicyEnforcementMode.PERMISSIVE). Deployments using Keycloak's default ENFORCING policy enforcement mode are not affected by this flaw.

According to Exploit Prediction Scoring System (EPSS) metrics, CVE-2026-9799 has an EPSS score of 0.00294 (0.29%), placing it in the 21.98th percentile. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and there is no evidence of active exploitation in the wild.

To remediate CVE-2026-9799, administrators should upgrade Keycloak to a release containing commit bdb4db353a8b6042eac14ec26e1857138234bfd2. For upstream Keycloak deployments, upgrade to version 26.6.4 or 26.4.13 (or later). For Red Hat build of Keycloak environments, apply the corresponding security errata to upgrade the 26.4 branch to 26.4.13-1 (26.4-19) and the 26.6 branch to 26.6.4-2 (26.6-8).

> [!NOTE] > Deployments that have not altered the default ENFORCING policy enforcement mode on their resource servers are not vulnerable to this issue.

For environments where an immediate version upgrade cannot be performed, two configuration workarounds are available to eliminate the exposure:

1. Switch Policy Enforcement Mode to ENFORCING: In the Keycloak Administration Console, navigate to Clients -> select the target Client / Resource Server -> Authorization -> Settings, and change Policy Enforcement Mode from PERMISSIVE to ENFORCING. Before applying this change in production, verify that all non-UMA resources on the client have appropriate explicit authorization policies attached so legitimate traffic is not disrupted.
2. Attach an Explicit Policy to the Resource Type: If PERMISSIVE mode is strictly required by the application architecture, create an explicit administrative policy governing the resource type (for example, a default-deny or owner-check policy attached directly to the <type> definition). When a static policy is attached to the resource type, DefaultPolicyEvaluator evaluates that policy instead of falling through to the unguarded PERMISSIVE grant condition.