CVE-2026-93999 in Keycloak
Summary
by MITRE • 09/19/2026
A flaw was found in the OIDC protocol implementation of Keycloak, an open-source identity and access management solution. The issue occurs during the token refresh process when the server restores requested audiences from stored client IDs. Keycloak fails to verify if the target audience client is still enabled before issuing a new access token. This allows an application with an existing refresh token to continue obtaining valid access tokens for a disabled client, potentially bypassing administrative access controls for resource servers that rely on offline JWT validation.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/19/2026
The vulnerability identified in Keycloak represents a critical failure in the enforcement of identity and access management policies during the OpenID Connect protocol's token refresh mechanism. As an open-source identity and access management solution, Keycloak serves as a central authentication provider for numerous enterprise applications, making any deviation from its security model particularly significant. The flaw resides specifically within the logic that handles the restoration of requested audiences when a client presents a valid refresh token to obtain a new access token. In standard OIDC operations, clients request specific resources or scopes by defining target audiences in their initial authentication requests. When these tokens expire and are refreshed, Keycloak is designed to reconstruct the audience list from stored client identifiers associated with the original session. However, this reconstruction process lacks a crucial validation step: it does not verify whether the target audience client remains enabled within the system's configuration before issuing the new access token.
This technical flaw creates a state where administrative changes intended to revoke or disable access for specific clients are effectively ignored during the renewal of credentials. If an application possesses a valid refresh token, it can continue to request and receive active access tokens even after its corresponding client entry has been disabled by an administrator. This behavior contradicts the fundamental principle that disabling a client should immediately halt its ability to authenticate or authorize against protected resources. The issue is particularly insidious because it allows for a silent bypass of security controls rather than an immediate error, potentially leaving administrators unaware that their revocation efforts have failed until unauthorized access occurs.
The operational impact of this vulnerability is severe, primarily affecting resource servers and downstream applications that rely on offline JSON Web Token validation to determine authorization decisions. In many architectures, the identity provider issues tokens containing claims about user roles or permissions, but it does not actively validate every request against a central policy engine in real-time. Instead, relying services parse these JWTs locally to make access control decisions. Because Keycloak continues to issue validly signed and structured tokens for disabled clients, downstream systems will accept them as legitimate credentials. This enables attackers who have obtained refresh tokens through phishing, session hijacking, or other means to maintain persistent access to sensitive resources even after the victim's account has been suspended or the application client has been decommissioned by security teams.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-613 Insufficient Session Expiration. The failure to check the enabled status of the target audience during token issuance is a direct violation of access control policies defined in the system's configuration. Furthermore, it relates to ATT&CK technique T1078 Valid Accounts, as it allows an attacker to maintain valid authentication credentials for resources they should no longer have access to. The persistence mechanism provided by refresh tokens exacerbates this risk, turning what might be a temporary breach into a long-term unauthorized presence within the environment.
Mitigation strategies must address both immediate remediation and architectural resilience. The primary solution is to apply vendor-provided patches that update Keycloak versions where this logic has been corrected to include explicit checks for client enabled status during audience restoration. Organizations running unpatched instances should consider rotating refresh tokens or invalidating sessions associated with disabled clients as a temporary countermeasure, although this may impact legitimate users if not managed carefully. Long-term architectural improvements involve implementing short-lived access token lifetimes combined with frequent validation against the identity provider's introspection endpoint rather than relying solely on offline JWT parsing. This ensures that even if an old refresh token is used to generate a new access token, the resource server can verify current authorization status in real-time, thereby neutralizing the impact of stale or revoked credentials.