CVE-2026-93999: Keycloak-services: keycloak-services: token refresh continues issuing tokens for disabled audience clients
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.
Other sources
A Missing Authorization vulnerability was identified in the org.keycloak.protocol.oidc package of Keycloak. The flaw exists in the token refresh logic including standard token exchange refresh flows where the server restores audience claims from the original session without checking the current status of the target audience client via ClientModel.isEnabled. An attacker with a valid refresh token obtained while a target audience client was enabled can continue to refresh that token even after an administrator has disabled the target client. Successful exploitation allows the attacker to obtain newly signed access tokens containing the disabled client in the aud claim. This enables the attacker to maintain unauthorized access to resource servers that perform offline JWT verification, effectively bypassing the administrative action intended to revoke access.
— Red Hat
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Keycloak deployments are exposed where a previously enabled audience client is later disabled, and an application still holds a refresh token issued while that audience client was enabled. Resource servers that rely on offline JWT validation are specifically at risk of accepting the newly issued tokens.
What does an attacker need to exploit it?
The attacker needs a valid refresh token obtained while the target audience client was enabled. Exploitation occurs through token refresh, including standard token-exchange refresh flows, after the administrator disables that audience client.
Does disabling the audience client stop token refresh from issuing tokens for it?
No. The affected refresh logic restores requested audiences from stored client IDs without checking whether the target audience client is currently enabled, so it can continue issuing newly signed access tokens.