Bug 2539288 (CVE-2026-96447)

Summary:	CVE-2026-96447 keycloak-services: keycloak-services: Stateless token preferred_username fallback enables identity rebinding
Product:	[Other] Security Response	Reporter:	OSIDB Bzimport <bzimport>
Component:	vulnerability	Assignee:	Product Security <prodsec-ir-bot>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	aschwart, aszczucz, boliveir, drichtar, mposolda, pjindal, rmartinc, security-response-team, ssilvert, sthorger, vmuzikar
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:	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.	Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Deadline:	2026-12-22

Description OSIDB Bzimport 2026-09-23 09:41:17 UTC

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.