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 preferred_username 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 may_act 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.