CVE-2026-96447: Keycloak-services: keycloak-services: stateless token preferred_username fallback enables identity rebinding
A flaw was found in Keycloak's stateless token validation mechanism within the TokenManager.lookupUserFromStatelessToken function. When a sessionless access token is presented and the user ID in the sub claim is no longer found in the database, the system falls back to resolving the user via the preferredusername claim. Because service-account usernames are deterministic (service-account-clientId), deleting and recreating a client with the same client ID results in a new service account with a different internal ID but the same username. An attacker who possesses a valid, unexpired stateless token from the original client can present it after the client has been recreated. Keycloak will resolve the token to the new service account identity and issue a new token reflecting the new account's roles and permissions. In delegation scenarios involving the mayact claim, this can also result in a delegated token being issued for the new service account identity. Successful exploitation allows an attacker to impersonate the new service account and perform any actions or access any data authorized for that account.
Other sources
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.
— MITRE