Live › vulnerability › CVE-2026-3583
Go to dashboardWhen the allowed_scopes setting is enabled, the OAuth2 token introspection cache is not cleared right away after a token is revoked, so a revoked access token can be handed back to a client until the cache entry expires. The sources say the re-issued token is not accepted for API authorization, so the main effect is disrupted authentication, not unauthorized access.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 20:35 UTC. All times on this page are UTC.
Systems running an OAuth2 server with the allowed_scopes configuration enabled and an introspection cache in use. Deployments without allowed_scopes or without introspection caching are not described as affected. The sources do not name the product or versions.
No product ranges from the sources yet.
Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
When the allowed_scopes configuration is enabled, the OAuth2 token introspection mechanism does not immediately invalidate a token in the cache after a revocation request. This results in a scenario where an access token that was introspected immediately before a revocation request may be returned again to the client after revocation, until the relevant cache entry is cleared.
The security consequence is that a revoked access token may be re-issued to the client during the cache lifetime. While the re-issued token is not treated as valid for API authorization, affected users may be unable to obtain a new valid access token until the cache is cleared, which can disrupt authentication flows.
This page as .md · .json · in your agent: get_signal("CVE-2026-3583")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.