Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-11-06T06:16:45.070Z",
  "pubdate": "2026-11-06T06:16:45.070Z",
  "executiveSummary": "This vulnerability involves an improper session validation flaw within Keycloak's Standard Token Exchange V2 mechanism. The issue resides in the token issuance logic, which fails to enforce expiration constraints derived from the original token, instead defaulting to the requester client's configured lifetime.\nThe vulnerability allows an authenticated actor—such as a compromised service account—to indefinitely extend the duration of their access. By repeatedly performing a token exchange, an attacker can generate a new token with a refreshed lifetime, effectively bypassing administrative controls. Crucially, this persistence remains achievable even after the original client identity has been disabled by an administrator, as the exchange process generates a new, valid session rather than strictly validating the existing one.\nThe impact is a loss of session control and potential unauthorized persistence for compromised service accounts. Exploitation requires an already authenticated requester with permissions to perform token exchange. This poses a significant risk to systems relying on short-lived tokens to mitigate the impact of credential theft, as the security boundary enforced by token expiration is effectively neutralized by the flaw.",
  "technicalDetails": "The root cause of this vulnerability is a design flaw in the Token Exchange V2 implementation within Keycloak. When a token exchange request is processed, the system is expected to validate the incoming token's remaining validity period and ensure the resulting token is constrained by the original session's lifetime parameters. Instead, the implementation utilizes the requester client's security policy to dictate the lifetime of the newly minted token.\nIn a secure configuration, an exchanged token should inherit the expiration constraints of the subject token. By ignoring the original expiration metadata and applying the requester's policy, Keycloak allows for 'token refreshing' through the exchange mechanism. The attack flow is as follows: 1) The attacker obtains a valid token for an existing client or service account. 2) The attacker initiates a Standard Token Exchange V2 request using the acquired token. 3) The Keycloak server processes the exchange and issues a new token, granting it a fresh lifespan based on the configuration of the requester client. 4) The attacker repeats this process before the new token expires, creating a recursive chain of tokens.\nThis behavior is particularly dangerous in scenarios where administrative revocation or disabling of a client occurs. Because the exchange mechanism validates the requester's permission to perform exchanges rather than performing a deep state validation of the original client's status, the generated token is treated as an entirely new entity by the authorization server. Consequently, the new token remains valid even if the client used to obtain the initial token has been disabled in the Keycloak management console.\nThe vulnerability manifests within the exchange endpoint logic responsible for mapping and generating subject tokens. Because the token lifetime is recalculated during every exchange request using the requester's policy, the expiration time is effectively extended indefinitely. This bypasses the intended security architecture where access is tied to the lifecycle of the principal, transforming a short-lived token into a vehicle for long-term unauthorized access. Since this occurs at the protocol level, no specific payload is required, only the authorized use of the exchange endpoint by an authenticated entity."
}