CVE-2026-80184 in Keystone
Summary
by MITRE • 08/26/2026
In OpenStack Keystone before 29.0.3, tokens obtained via delegated authentication mechanisms (OAuth1 access tokens, application credentials, trusts) could be submitted to the token-method authentication path for reauthentication to escape their intended project scope. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, bypassing the intended project boundary. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in OpenStack Keystone prior to version 29.0.3 represents a critical authorization bypass within the cloud infrastructure's identity management service. This flaw specifically targets the token renewal and reauthentication mechanisms used for delegated authentication methods, including OAuth1 access tokens, application credentials, and trusts. In typical cloud environments, these delegation mechanisms are designed to allow services or users to act on behalf of others with strictly defined permissions. The core issue arises when a token obtained through one of these delegated paths is submitted to the standard token-method authentication endpoint for reauthentication without an explicit scope parameter provided by the client application. Under normal security expectations, such tokens should retain their original scoped boundaries or fail gracefully if no valid scope can be inferred from the delegation context. However, due to this implementation flaw, Keystone incorrectly interprets the absence of a specified scope as a request to issue a new token based on the credential owner's default project configuration rather than preserving the specific project scope for which the delegated credential was originally issued.
This behavior effectively allows an attacker or compromised service account to escalate privileges by escaping their intended project boundary. When an application credential token is presented without an explicit scope, Keystone issues a replacement token scoped to the default project of the credential owner. If that default project differs from the restricted project where the delegation was authorized, the resulting token grants access to resources outside the originally permitted domain. This bypasses the fundamental principle of least privilege enforced by OpenStack's multi-tenancy architecture. For deployments utilizing OAuth1, application credentials, or trusts, this means that any component holding a delegated token could potentially interact with services and data in unrelated projects, leading to unauthorized data access, configuration changes, or further lateral movement within the cloud environment. The impact is particularly severe because it undermines the isolation guarantees between tenants, which are foundational to secure multi-tenant operations.
From a technical classification perspective, this vulnerability aligns closely with CWE-269, Improper Privilege Management, as it involves an elevation of privilege through incorrect handling of authorization contexts. It also relates to CWE-807, Reliance on Untrusted Inputs in Security Decision, because the system relies on the presence or absence of a scope parameter without adequately validating whether that absence should trigger a fallback to default scopes rather than maintaining strict delegation boundaries. In terms of attack vectors and tactics, this flaw facilitates lateral movement within an environment by allowing compromised credentials to access broader resources than intended. It maps to MITRE ATT&CK techniques such as T1078, Valid Accounts, specifically the sub-technique involving legitimate accounts with elevated privileges obtained through misconfiguration or exploitation of trust relationships. The ability to escape project scopes enables attackers to pivot from a low-privilege tenant account to higher-value resources across different projects, significantly expanding the blast radius of an initial compromise.
Mitigation for this vulnerability requires immediate upgrading of OpenStack Keystone to version 29.0.3 or later, where the logic governing token reauthentication has been corrected to respect the original scope of delegated tokens rather than defaulting to owner-specific project scopes. For environments that cannot immediately upgrade, administrators should review configurations related to application credentials and trusts to ensure that explicit scoping is enforced at the client level whenever possible. Additionally, implementing strict network segmentation between tenant projects can limit the potential impact if a token is successfully misused. Security teams should also audit logs for unusual patterns of token reauthentication requests lacking scope parameters, as these may indicate exploitation attempts. Regularly rotating application credentials and minimizing the use of default project scopes in credential definitions further reduces the risk surface associated with this type of authorization bypass.