CVE-2026-80182 in Keystone
Summary
by MITRE • 08/25/2026
In OpenStack Keystone before 29.0.3, tokens obtained via OAuth1 access token, application credential, or trust-scoped authentication could create new long-lived credentials or authorize new delegations that persist independently of, and outlive, the credential used to obtain them. The delegation restrictions that block these operations did not consistently apply to all delegated token types, allowing an OAuth1-scoped token, for example, to create application credentials or authorize OAuth1 request tokens despite those operations being restricted for other delegated token types. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in OpenStack Keystone prior to version 29.0.3 represents a critical authorization bypass within the cloud computing platform's identity management subsystem. This flaw stems from an inconsistency in how delegation restrictions are enforced across different types of delegated tokens, specifically affecting OAuth1 access tokens, application credentials, and trust-scoped authentication mechanisms. In standard OpenStack deployments, administrators configure policies to restrict what actions certain roles or token types can perform, particularly regarding the creation of new long-lived credentials or the authorization of further delegations. These restrictions are designed to prevent privilege escalation by ensuring that a temporary or limited credential cannot be used to generate permanent administrative access or extend its own lifespan indefinitely through nested delegation chains. However, in versions before 29.0.3, this policy enforcement logic failed to uniformly apply these constraints across all delegated token types.
The technical root cause lies in the authentication and authorization flow where specific code paths for OAuth1-scoped tokens bypassed the validation checks that were correctly implemented for other delegation methods such as standard trust scopes or application credentials. When a user authenticates via an OAuth1 access token, which is typically intended to provide limited, scoped API access rather than administrative control, the system incorrectly allowed this token type to invoke endpoints responsible for creating new application credentials or authorizing additional request tokens. This behavior contradicts the security model where delegated tokens should have strictly bounded capabilities that do not exceed those of their parent credential. Consequently, an attacker possessing a valid OAuth1 access token could exploit this inconsistency to generate long-lived application credentials or authorize further delegations that persist independently of the original token's lifecycle and restrictions.
The operational impact of this vulnerability is severe, as it effectively allows for privilege escalation within the OpenStack environment. An unauthorized actor who obtains an OAuth1 access token through social engineering, credential theft, or other means could leverage this flaw to create persistent backdoors in the form of new application credentials. These newly created credentials are not subject to the expiration policies or scope limitations that applied to the original OAuth1 token, thereby granting the attacker long-term administrative control over cloud resources. This undermines the principle of least privilege and compromises the integrity of multi-tenant environments where strict isolation between tenants is required for security compliance. The ability to authorize new delegations further exacerbates the risk by enabling lateral movement within the infrastructure, potentially leading to full compromise of the OpenStack deployment including compute instances, storage volumes, and network configurations managed through Keystone.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically regarding the failure to enforce restrictions on delegated privileges. It also maps to MITRE ATT&CK techniques related to Account Manipulation and Defense Evasion, as an attacker can create new accounts or credentials that persist beyond the original access vector, effectively maintaining unauthorized presence in the system despite remediation of the initial entry point. The flaw highlights a common challenge in complex identity systems where policy enforcement must be rigorously tested across all authentication flows to ensure consistent security postures.
To mitigate this vulnerability, organizations running OpenStack Keystone versions prior to 29.0.3 should immediately upgrade to version 29.0.3 or later, which contains the necessary patches to enforce delegation restrictions uniformly across OAuth1, application credentials, and trust-scoped authentication paths. In addition to upgrading, administrators should audit existing policies for any overly permissive rules that might have been exploited by this flaw and ensure that future deployments undergo rigorous security testing of all delegated token types. Monitoring logs for unusual creation events of long-lived credentials or new delegations can also help detect potential exploitation attempts in environments where immediate patching is not feasible, although upgrading remains the definitive remediation strategy to eliminate the underlying code defect.