CVE-2026-9800: Authorization Bypass in Keycloak Policy Enforcer via Unnormalized URI Substring Matching

The Keycloak Policy Enforcer (org.keycloak:keycloak-policy-enforcer and servlet-policy-enforcer) functions as a security interceptor for Java servlet containers and Quarkus applications. Its primary architectural role is to intercept incoming HTTP requests targeting protected resource servers, inspect bearer access tokens, and enforce fine-grained authorization policies configured within Keycloak Authorization Services. This enforcement encompasses Role-Based Access Control (RBAC), OAuth2 scope validation, and User-Managed Access (UMA) permission ticket verification.

When a request fails policy evaluation in web applications, the Policy Enforcer can redirect the client to a designated error or landing page defined by the on-deny-redirect-to configuration property (which commonly defaults to /access-denied). To prevent infinite redirection loops when the client subsequently requests this error page, the enforcer checks whether the incoming request targets the configured access-denied URI. If a match occurs, the enforcer exempts the request from policy evaluation and permits it to proceed through the filter chain.

Classified under CWE-1025 (Comparison Using Wrong Factors), CVE-2026-9800 occurs because the exemption check in PolicyEnforcer.isDefaultAccessDeniedUri performs an unanchored substring search (String.contains) across the entire raw URI string instead of comparing the canonicalized request path against the configured redirect path. Because the raw URI includes subpaths and query parameters, an attacker can inject the access-denied string anywhere into the request target.

This flaw exposes a critical attack surface across any microservice or web application relying on the Keycloak Policy Enforcer with on-deny-redirect-to enabled. Any authenticated user holding a valid bearer token—regardless of their assigned roles or permissions—can completely bypass authorization enforcement, resulting in unauthorized read and write access to protected APIs and administrative endpoints.

The root cause of CVE-2026-9800 resides in the implementation of the isDefaultAccessDeniedUri method within the PolicyEnforcer class. During the request interception lifecycle, the enforcer invokes this method to determine whether the current HTTP request is attempting to load the access-denied landing page configured via getOnDenyRedirectTo().

Two distinct design flaws converge in this method to create the vulnerability. First, the method retrieves the target identifier via request.getUri(), which returns the complete, unparsed URI string—including the scheme, authority, path, and raw query string (?param=value)—rather than isolating the path component via a dedicated path extraction method. Second, the method compares this raw string against the configured accessDeniedUri using uri.contains(accessDeniedUri).

When isDefaultAccessDeniedUri evaluates to true, the Policy Enforcer immediately short-circuits the authorization pipeline and treats the request as authorized. This premature exit bypasses PolicyEvaluator.evaluate(), skipping all configured role checks (hasRole()), scope validations (hasScope()), and UMA ticket negotiations.

Consequently, there is a parser differential between how the Keycloak Policy Enforcer evaluates exemptions and how the downstream servlet container or JAX-RS router dispatches the request. While the enforcer sees the substring /access-denied inside a query parameter and grants access, the downstream web framework ignores the unknown query parameter and routes the request directly to the restricted controller method.

In vulnerable versions of org.keycloak:keycloak-policy-enforcer (versions <= 26.0.5), the isDefaultAccessDeniedUri method inspects the incoming HttpRequest object without parsing or normalizing the URI structure.

// Vulnerable implementation in PolicyEnforcer.java
public boolean isDefaultAccessDeniedUri(HttpRequest request) {
    // Flaw 1: Retrieves the full raw URI, including query parameters
    String uri = request.getUri();
    String accessDeniedUri = getConfiguration().getOnDenyRedirectTo();
    
    if (accessDeniedUri != null) {
        // Flaw 2: Uses loose substring matching instead of exact path equality
        return uri.contains(accessDeniedUri);
    }
    return false;
}

To remediate this vulnerability, the comparison logic must be restricted to the normalized path component of the URI, and the substring check must be replaced with an exact match or canonicalized boundary check.

// Patched implementation pattern
public boolean isDefaultAccessDeniedUri(HttpRequest request) {
    String accessDeniedUri = getConfiguration().getOnDenyRedirectTo();
    
    if (accessDeniedUri != null) {
        // Fix 1: Parse the URI, normalize path traversal segments, and extract strictly the path
        String requestPath = URI.create(request.getUri()).normalize().getPath();
        
        // Fix 2: Enforce exact equality between the canonical request path and the configured path
        return requestPath.equals(accessDeniedUri);
    }
    return false;
}

By invoking URI.create(request.getUri()).normalize().getPath(), the patched logic strips all query strings (?...) and fragments (#...), while also resolving relative path segments (such as /../ or /./). Replacing String.contains() with String.equals() ensures that requests to subpaths like /api/resource/access-denied do not falsely match a root-level /access-denied configuration.

This fix effectively eliminates both query parameter injection and subpath appending variants. However, application developers must still ensure that downstream servlet containers and reverse proxies normalize URIs consistently (for example, handling matrix parameters like ;jsessionid= or encoded slashes %2F) so that the path evaluated by URI.normalize().getPath() strictly matches the path dispatched by the application router.

Exploiting CVE-2026-9800 requires three conditions: the target application must protect its endpoints using the Keycloak Policy Enforcer, the on-deny-redirect-to configuration property must be defined, and the attacker must possess a valid authentication token for any user account recognized by the Keycloak realm. Because the Policy Enforcer validates token authenticity prior to evaluating authorization exemptions, unauthenticated requests without a valid bearer token will still be rejected.

An attacker can trivially discover the configured on-deny-redirect-to value by sending a standard request with a low-privileged token to a restricted endpoint and inspecting the Location header in the resulting HTTP 302 Found or 403 Forbidden response. Once the path (typically /access-denied) is known, the attacker can execute the bypass using either query parameter injection or path appending.

Attack Vector 1: Query Parameter Injection

Query parameter injection is the most reliable exploitation vector because downstream REST controllers generally ignore unrecognized query parameters. The attacker appends a dummy query key containing the access-denied path to the restricted API endpoint:

GET /api/v1/admin/users?bypass=/access-denied HTTP/1.1
Host: api.target-domain.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Accept: application/json

When the Policy Enforcer intercepts this request, request.getUri() returns /api/v1/admin/users?bypass=/access-denied. The check uri.contains("/access-denied") returns true, bypassing authorization. The underlying JAX-RS or Spring controller receives the request at /api/v1/admin/users, ignores the bypass parameter, and returns the sensitive administrative user list.

Attack Vector 2: Subpath Appending

For endpoints configured with wildcard routing or hierarchical path parameters, an attacker can append the access-denied string directly as a trailing path segment:

GET /api/v1/confidential-records/access-denied HTTP/1.1
Host: api.target-domain.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

In this scenario, uri.contains("/access-denied") again evaluates to true. If the backend endpoint maps routes using patterns such as /api/v1/confidential-records/*, the application processes the request and exposes the protected resource.

CVE-2026-9800 carries a CVSS v3.1 base score of 8.1 (High) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. The attack complexity is low (AC:L) and requires no user interaction (UI:N), as exploitation involves simple URL string manipulation over the network (AV:N). Privileges required is rated low (PR:L) because the attacker must authenticate as a standard user before reaching the policy enforcement stage.

The confidentiality and integrity impacts are both rated high (C:H/I:H). Because the vulnerability disables the entire policy evaluation engine for matching requests, an attacker can read any protected resource across the application (GET) and execute state-changing administrative operations (POST, PUT, DELETE). Multi-tenant applications that rely on Keycloak UMA permissions or fine-grained scopes to isolate tenant data are exposed to cross-tenant data access and manipulation.

The availability impact is rated none (A:N) in the standard CVSS vector because the flaw in the URI check does not directly trigger memory exhaustion, application crashes, or thread deadlocks. However, if an application exposes administrative endpoints capable of deleting system resources or shutting down services, an attacker could leverage the integrity bypass to cause secondary service disruption.

According to threat intelligence telemetry, CVE-2026-9800 has an EPSS score of 0.00651 (51.09th percentile), indicating a moderate baseline probability of exploitation. While a functional proof-of-concept is publicly documented via Red Hat Bugzilla #2482472, the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

Organizations utilizing the Keycloak Policy Enforcer within Java servlet applications or Quarkus microservices should upgrade to the patched component releases provided by Red Hat and the upstream Keycloak project. Specifically, deployments of Red Hat build of Keycloak must be upgraded to versions 26.4.13+ (for the 26.4 stream) or 26.6.4-2+ (for the 26.6 stream). Applications built on Red Hat build of Quarkus should update their platform dependencies to incorporate org.keycloak:keycloak-policy-enforcer version 26.0.10.redhat-00001 or later.

> [!NOTE] > Updating the central Keycloak identity server alone does not remediate this vulnerability. Because keycloak-policy-enforcer runs as an adapter library embedded within client applications and resource servers, every affected microservice and servlet application must be rebuilt and redeployed with the patched library.

For environments where immediate application rebuilding is not feasible, administrators can disable the on-deny-redirect-to configuration property in keycloak.json or application.properties if custom redirect pages are not strictly required (for example, in pure REST APIs where returning a raw HTTP 403 Forbidden status code is sufficient). When on-deny-redirect-to is null or unset, isDefaultAccessDeniedUri returns false and the vulnerable comparison is never executed.

Alternatively, security teams can deploy Web Application Firewall (WAF) or reverse proxy rules (such as NGINX or ModSecurity) in front of vulnerable services to inspect and block incoming requests that contain the access-denied path segment within query strings or non-root URI paths.