Red Hat Keycloak CVE-2026-9705

Exploitation requires the attacker to possess a valid Registration Access Token previously issued for the target Keycloak client - either legitimately obtained during an earlier registration, stolen from storage, or exposed via logs or configuration files. The targeted client must have been disabled by an administrator (this is the security control being bypassed). The attacker must be able to reach the Keycloak client registration REST endpoint over the network. Limiting factors: the RAT must correspond to the specific client being targeted; if the RAT has been explicitly revoked (separate from client disablement), exploitation fails; environments that never disable clients rather than deleting them are not directly exposed to the bypass scenario. The CVSS vector PR:N does not reflect the token-possession requirement - authentication requirements are more accurately described as requiring prior possession of a valid bearer token credential for the targeted client.

The NVD-assigned CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) warrants scrutiny: the PR:N designation implies no prior privileges are required, but the vulnerability description explicitly states the attacker must possess a 'previously issued Registration Access Token.' A RAT is a bearer credential - its possession constitutes a form of low-level privilege, making PR:L a more accurate independent assessment. This discrepancy inflates the NVD score from what is more realistically a medium-low severity. There is no EPSS data available to quantify exploitation probability, no CISA KEV listing, and no confirmed public proof-of-concept code. The practical impact is significant in environments where administrators use client disablement as a security control - an assumption a defender might reasonably make - since this vulnerability nullifies that control. Real-world risk is elevated for Keycloak deployments where RATs may have been distributed broadly or are not rotated regularly, but is constrained by the prerequisite of token possession.

An attacker who previously registered an OAuth2 client in a Keycloak realm and retained the issued RAT, or who acquired the RAT through credential theft or exposure, sends an authenticated PUT request to the Keycloak client registration endpoint using that token against a client the administrator has since disabled. Keycloak processes the request without checking the client's disabled status, re-enables the client, and allows the attacker to rotate the client secret - restoring full OAuth2/OIDC API access that was intentionally revoked. No public proof-of-concept has been identified, but the attack is mechanically straightforward for anyone with a valid RAT.