CVE-2026-9705: Registration Access Token Authorization Bypass in Keycloak Dynamic Client Registration

Keycloak is an open-source identity and access management solution that provides single sign-on, identity brokering, and standard protocol implementations for OpenID Connect, OAuth 2.0, and SAML 2.0. As part of its OAuth 2.0 and OpenID Connect capabilities, Keycloak implements the OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591) and the OAuth 2.0 Dynamic Client Registration Management Protocol (RFC 7592). These specifications expose RESTful HTTP endpoints at /realms/{realm-name}/clients-registrations/{provider} that allow relying parties and client applications to dynamically register and manage their lifecycle within a Keycloak realm.

When a client registers dynamically, Keycloak issues a Registration Access Token (RAT) alongside the client configuration metadata. The RAT is a bearer JSON Web Token (JWT) scoped specifically to that individual client entity. It authorizes the holder to execute subsequent HTTP GET, PUT, and DELETE operations against the client registration endpoint without requiring privileged realm administrator credentials. This self-service architecture allows automated systems to rotate client secrets, update redirect URIs, or decommission themselves.

CVE-2026-9705, classified under CWE-613 (Insufficient Session Expiration), is a state validation flaw within the authentication handler for the Dynamic Client Registration service (ClientRegistrationAuth). When an administrator disables a client via the Keycloak Admin Console or Admin REST API by setting its enabled attribute to false, Keycloak blocks the client from performing standard OAuth 2.0 authentication flows or obtaining access tokens. However, the client registration authentication service did not evaluate the client.isEnabled() property when validating incoming bearer RATs.

Because the registration token remained valid across administrative state changes, an entity holding a previously issued RAT could continue interacting with the management endpoint of a disabled client. More critically, because the PUT update handler permits modifying the enabled attribute within the submitted ClientRepresentation payload, the token holder could directly overwrite the disabled state, reactivate the client, and retrieve or rotate its authentication secrets.

The root cause of CVE-2026-9705 resides in org.keycloak.services.clientregistration.ClientRegistrationAuth, the class responsible for enforcing authentication and authorization policies on all requests targeting the /clients-registrations endpoints. When a request arrives at the endpoint to inspect (GET), modify (PUT), or remove (DELETE) a specific client, the service invokes either requireView() or requireUpdateAuth() to verify the caller's credentials.

Keycloak supports multiple authentication mechanisms for client registration endpoints, including realm administrator bearer tokens, Initial Access Tokens (IATs), and Registration Access Tokens (RATs). When the caller authenticates using a RAT, ClientRegistrationAuth confirms that the token carries the expected token type (isRegistrationAccessToken()) and then validates the binding between the JWT and the target ClientModel stored in the Keycloak database.

Prior to the patch, both requireView() and requireUpdateAuth() validated the RAT by checking three conditions: that the ClientModel reference was non-null (client != null), that the model held an assigned registration token identifier (client.getRegistrationToken() != null), and that the model's registration token identifier matched the jti (JWT ID) claim of the incoming bearer token (client.getRegistrationToken().equals(jwt.getId())). Neither method verified whether the ClientModel itself was currently enabled (client.isEnabled()).

When a realm administrator disables a client in Keycloak, the underlying ClientModel persists in the database with its enabled flag set to false, while its registrationToken attribute remains intact and unrotated. Because the authentication logic omitted the client.isEnabled() check, the RAT passed validation. Subsequently, when the update endpoint deserialized the incoming JSON representation and applied it to the ClientModel, any `

The vulnerability was resolved in upstream commit be81d60b21850569951f72baac0c32c97a927cf6 (Pull Request #50349). The patch modifies services/src/main/java/org/keycloak/services/clientregistration/ClientRegistrationAuth.java to enforce the client.isEnabled() state check during Registration Access Token verification across both view and update code paths.

--- a/services/src/main/java/org/keycloak/services/clientregistration/ClientRegistrationAuth.java
+++ b/services/src/main/java/org/keycloak/services/clientregistration/ClientRegistrationAuth.java
@@ -213,7 +213,7 @@ public void requireView(ClientModel client, boolean allowPublicClient) {
                 throw forbidden();
             }
         } else if (isRegistrationAccessToken()) {
-            if (client != null && client.getRegistrationToken() != null && client.getRegistrationToken().equals(jwt.getId())) {
+            if (client != null && client.isEnabled() && client.getRegistrationToken() != null && client.getRegistrationToken().equals(jwt.getId())) {
                 checkClientProtocol(client);
                 authenticated = true;
                 authType = getRegistrationAuth();
@@ -325,7 +325,7 @@ private RegistrationAuth requireUpdateAuth(ClientModel client) {
                 throw forbidden();
             }
         } else if (isRegistrationAccessToken()) {
-            if (client != null && client.getRegistrationToken() != null && client.getRegistrationToken().equals(jwt.getId())) {
+            if (client != null && client.isEnabled() && client.getRegistrationToken() != null && client.getRegistrationToken().equals(jwt.getId())) {
                 return getRegistrationAuth();
             }
         }

In requireView(ClientModel client, boolean allowPublicClient) at line 216, adding client.isEnabled() ensures that if the client is disabled, the authenticated boolean remains false. Execution then falls through the conditional block and throws an HTTP 401 Unauthorized exception (throw unauthorized("Not authorized to view client. Not valid token or client disabled")). The identical condition added to requireUpdateAuth(ClientModel client) at line 328 prevents both PUT (update) and DELETE operations from succeeding when authenticated via a RAT on a disabled client.

To verify the fix and prevent regressions, the commit added the testDisabledClientWithRegistrationToken() integration test in testsuite/integration-arquillian/tests/base/src/test/java/org/keycloak/testsuite/client/RegistrationAccessTokenTest.java:

@Test
public void testDisabledClientWithRegistrationToken() {
    // Administrator explicitly disables the target client
    ClientRepresentation adminRep = adminClient.realm(REALM_NAME).clients().get(client.getId()).toRepresentation();
    adminRep.setEnabled(false);
    adminClient.realm(REALM_NAME).clients().get(client.getId()).update(adminRep);
 
    // Attempting to read configuration with the RAT now returns HTTP 401
    try {
        reg.get(client.getClientId());
        fail("Should not be able to get a disabled client using a registration access token");
    } catch (ClientRegistrationException e) {
        assertEquals(401, ((HttpErrorException) e.getCause()).getStatusLine().getStatusCode());
    }
 
    // Attempting to re-enable the client with the RAT now returns HTTP 401
    try {
        client.setEnabled(true);
        reg.update(client);
        fail("Should not be able to update a disabled client using a registration access token");
    } catch (ClientRegistrationException e) {
        assertEquals(401, ((HttpErrorException) e.getCause()).getStatusLine().getStatusCode());
    }
}

> [!NOTE] > Fix Completeness Assessment: The patch is complete and directly addresses the root cause within the centralized authentication gatekeeper for all client registration providers (default, openid-connect, and saml2-entity-descriptor). Note that by design, an active client can still use its own RAT to set enabled: false on itself, which immediately revokes the RAT's ability to perform any further actions until a realm administrator re-enables the client via the Admin API.

Exploiting CVE-2026-9705 requires no specialized tooling beyond a standard HTTP client and possession of a previously issued Registration Access Token (RAT) for a client within the target Keycloak realm. A RAT is normally obtained when a client is initially created via an Initial Access Token (IAT), through anonymous dynamic client registration (subject to realm policy restrictions), or when an administrator manually generates a new registration token for an existing client in the Keycloak Admin Console under the client's Credentials tab.

Consider an operational scenario where a client application's environment is compromised, or an integration partner's access needs to be suspended during an incident response investigation. The Keycloak administrator responds by navigating to the client settings and toggling the client's status to Disabled (enabled: false), rather than deleting the client entity entirely, in order to preserve audit logs, role mappings, and protocol mappers.

To bypass this revocation, the attacker possessing the compromised RAT constructs an HTTP PUT request targeting either the default Keycloak client registration provider (/realms/{realm}/clients-registrations/default/{client-id}) or the OpenID Connect provider (/realms/{realm}/clients-registrations/openid-connect/{client-id}).

PUT /realms/production/clients-registrations/default/compromised-service-client HTTP/1.1
Host: idp.example.com
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6IC...
Content-Type: application/json
 
{
  "clientId": "compromised-service-client",
  "enabled": true,
  "redirectUris": [
    "https://attacker.example.net/callback"
  ],
  "publicClient": false,
  "serviceAccountsEnabled": true
}

Upon receiving this request, an unpatched Keycloak instance validates the Bearer token in ClientRegistrationAuth.requireUpdateAuth(), confirms that the jti claim matches the stored registrationToken on compromised-service-client, and applies the JSON representation to the database. The server responds with an HTTP 200 OK containing the updated client metadata, including a newly issued registrationAccessToken and the client's secret. At this point, the client is active again, and the attacker can immediately request OAuth 2.0 access tokens using the client credentials grant or redirect flows.

CVE-2026-9705 is rated with a CVSS v3.1 base score of 6.5 (Medium) via the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N. The Attack Vector is Network (AV:N) because the Dynamic Client Registration endpoints are exposed over the primary HTTP/HTTPS interface alongside standard token and authorization endpoints. Privileges Required is scored as None (PR:N) in the context of standard user accounts, though successful exploitation strictly depends on the precondition that the attacker already possesses a valid Registration Access Token.

The primary security impact is the subversion of administrative incident response and access revocation controls. In enterprise identity deployments, administrators routinely disable rather than delete OAuth 2.0 clients to avoid breaking foreign-key relationships, losing complex scope and mapper configurations, or invalidating historical audit references. When CVE-2026-9705 is exploited, disabling a client fails to contain a credential leak if the RAT was included in the exposed configuration material.

Furthermore, the impact extends depending on the specific permissions and configuration assigned to the disabled client prior to deactivation. If the disabled client was configured with serviceAccountsEnabled: true and granted high-privilege realm management roles (such as realm-admin, manage-users, or manage-clients), re-enabling the client via the RAT allows the attacker to immediately authenticate via the client_credentials grant and escalate privileges to full realm control.

Even for standard confidential or public clients without service accounts, re-enabling the client and modifying its redirectUris allows an attacker to initiate authorization code flows against realm users. According to threat intelligence metrics, the vulnerability currently carries an EPSS score of 0.00464 (40.18th percentile), indicating a low probability of automated mass exploitation due to the requirement of possessing a realm-specific RAT.

The definitive remediation for CVE-2026-9705 is to upgrade Keycloak to a patched version that enforces the client.isEnabled() verification check during Registration Access Token authentication. Upstream Keycloak users must upgrade to version 26.6.4 or 26.4.13 (or subsequent releases). Organizations running the supported Red Hat build of Keycloak must apply the relevant security errata (RHSA-2026:30049, RHSA-2026:30050, RHSA-2026:30083, or RHSA-2026:30084) to bring their deployments to 26.4.13-1 (26.4-19) or 26.6.4-2 (26.6-8).

For environments where an immediate software upgrade cannot be scheduled, administrators can implement network-layer access controls to neutralize the attack vector. Because Dynamic Client Registration is handled under a dedicated URI path hierarchy, reverse proxies, ingress controllers, API gateways, or web application firewalls (WAFs) should be configured to block external requests targeting /realms/*/clients-registrations/*. Access to these paths should be restricted exclusively to trusted internal networks or eliminated entirely if dynamic client registration is not utilized.

# Example Nginx reverse proxy rule to block external access to Client Registration endpoints
location ~* ^/realms/[^/]+/clients-registrations/ {
    allow 10.0.0.0/8;
    deny all;
    return 403;
}

In addition to network restrictions, administrators running unpatched instances who must revoke a compromised or decommissioned client without deleting it can explicitly invalidate its Registration Access Token. Navigating to the client's Credentials tab in the Keycloak Admin Console and clicking Regenerate registration access token rotates the internal registrationToken identifier on the ClientModel, rendering any previously issued RATs held by external parties invalid.