Live › vulnerability › CVE-2026-9705
Keycloak's client registration service lets someone holding a previously issued Registration Access Token re-enable a client that an administrator disabled. The attacker can then reset that client's secret and may regain privileged API access.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-29 16:39 UTC, 0h before NVD. All times on this page are UTC.
Teams running self-hosted Keycloak versions below 26.6.4 that use client registration and have issued Registration Access Tokens. An attacker needs a token that was issued before the client was disabled, so deployments that do not use dynamic client registration or that have not issued such tokens are less exposed.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| org.keycloak:keycloak-services | maven | < 26.6.4 | 26.6.4 |
| redhat build of keycloak | vendor | >= 26.4, < 26.4.13 | 26.4.13 |
| redhat build of keycloak | vendor | >= 26.6, < 26.6.4 | 26.6.4 |
keycloak-services below .26.6.4keycloak-services 26.6.4Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
A flaw was found in Keycloak's client registration service. A remote attacker, possessing a previously issued Registration Access Token (RAT), could exploit this vulnerability to re-enable a client that an administrator had explicitly disabled. This bypasses security controls, allowing the attacker to reset the client's secret and potentially regain privileged API access. The primary impact includes unauthorized information disclosure and potential integrity compromise.
This page as .md · .json · in your agent: get_signal("CVE-2026-9705")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.