CVE-2026-96447 · Package
NO FIX YET
Keycloak falls back to matching a user by username when the original user ID no longer exists while validating stateless access tokens. An attacker holding an old token could gain access to a newly created service account that reuses the client ID of a deleted one.
first public Nov 6, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Teams running Keycloak as their identity provider that use stateless access tokens and delete and recreate service accounts or clients with the same client ID. The sources do not give the affected version range, and the flaw needs an old token that was issued before the deletion.
Not affected if no-service-account-reuse
Who cares keycloak, self-hosted, service-accounts
Unknown from the sources.
No fix yet, per the 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.
This page as .md · .json · CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.