CVE-2026-96460: Keycloak-services: keycloak-services: indefinite access token renewal via standard token exchange v2
A flaw was found in the token exchange mechanism of Keycloak. When using Standard Token Exchange V2, the system issues new tokens with a fresh lifetime based on the requester clients configuration instead of limiting it to the original tokens expiration. This issue allows an authenticated requester to indefinitely extend access for service accounts by repeatedly exchanging tokens, even if the original client has been disabled by an administrator.
Other sources
A vulnerability was found in Keycloaks Standard Token Exchange V2 implementation within the org.keycloak.protocol.oidc.tokenexchange package. The root cause is that exchanged tokens are issued with a new access-token lifetime derived from the requester clients configuration, failing to bound the new tokens expiration by the subject tokens original expiration time. For service accounts which lack a session ID, this creates a chain where a requester client can indefinitely refresh access by performing a new exchange before the current token expires. The vulnerability persists even if an administrator disables the origin client, as Keycloak continues to accept exchanges of previously exchanged tokens associated with the requester client. An attacker with a valid service-account token and the requester clients credentials can maintain persistent, unauthorized access to resources beyond the intended security lifecycle.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Which environments are exposed to this issue?
The issue affects deployments using Standard Token Exchange V2, particularly exchanges involving service accounts that lack a session ID. The vulnerable behavior occurs when a requester client can exchange tokens before their current lifetime expires.
What access does an attacker need?
An attacker needs to be an authenticated requester able to perform token exchanges. They can repeatedly exchange tokens to obtain new tokens whose lifetime is based on the requester client's configuration.
Does disabling the original client stop the token-renewal chain?
No. Previously exchanged tokens associated with the requester client can continue to be accepted for exchange even after an administrator disables the origin client, allowing access to be extended indefinitely.