Description

A flaw was found in the TokenManager component of Keycloak, an open-source identity and access management solution. The issue occurs during the validation of stateless access tokens when the original user ID no longer exists. Keycloak incorrectly falls back to using the username to identify the user without verifying if the identity matches the original token subject. This could allow an attacker with an old token to gain access to a newly created service account if it shares the same client ID as a previously deleted one.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.2",
  "pubDate": "2026-11-06T06:16:44.910Z",
  "pubdate": "2026-11-06T06:16:44.910Z",
  "executiveSummary": "A critical security flaw exists within the TokenManager component of Keycloak involving the improper validation of stateless access tokens.\nThe vulnerability occurs when a user identity referenced in an existing access token is deleted from the system, causing the TokenManager to incorrectly transition to username-based lookup without validating the subject-to-identity mapping.\nThis flaw allows for unauthorized access escalation if an attacker possesses a stale access token and a newly created entity (such as a service account) is assigned the same identifier as the previously deleted user.\nThe vulnerability poses a significant risk to identity integrity, potentially allowing attackers to masquerade as privileged service accounts.\nExploitation requires the attacker to possess an invalidated token and relies on a race condition or predictable identity provisioning where a new account reuses the subject identifier of a deleted record.\nImpacts include unauthorized access to protected resources and the potential for privilege escalation within the identity management ecosystem.",
  "technicalDetails": "The vulnerability resides in the TokenManager component, specifically during the stateless token validation lifecycle. When Keycloak parses an incoming access token, it attempts to resolve the 'sub' (subject) claim to a valid security principal.\nIn scenarios where the original user record associated with the subject identifier is purged from the persistent store, the validation logic fails to strictly enforce subject binding. Instead of rejecting the token due to an invalid or missing principal, the component triggers a fallback mechanism.\nThis fallback mechanism attempts to resolve the identity based on the username claim associated with the token. The implementation error lies in the lack of cross-verification between the identity extracted from the username lookup and the original subject identifier encoded in the cryptographic payload.\nAn attacker can exploit this by capturing a stateless access token before the deletion of the original user account. If the environment is dynamic—such as in microservices or automated CI/CD pipelines—where service accounts are frequently re-provisioned, the attacker can leverage the stale token against a newly created account that happens to adopt the decommissioned user's credentials or identifiers.\nThe attack flow follows these steps: 1) An attacker obtains a stateless token for a user account that is subsequently deleted. 2) The TokenManager, upon receiving the stale token, fails to find the subject in the user database. 3) The logic pivots to secondary lookup methods, resolving the username. 4) The application incorrectly assumes the identity is valid because the secondary lookup succeeds, bypassing the explicit check that the authenticated principal matches the token's original subject ID. 5) The attacker gains the security context of the newly created service account, inheriting its permissions.\nThe vulnerability is primarily triggered due to insufficient state validation in the TokenManager logic. It requires no specific network-level privileges beyond the ability to present a token to the authentication endpoint, but success is contingent upon the predictable collision of identity identifiers in the target Keycloak environment."
}