OpenStack Keystone delegated tokens could create persistent credentials and escape project scope
OSSA-2026-037 covers CVE-2026-80182 and CVE-2026-80184: delegated tokens could extend access lifetime and cross an intended project boundary.
- AUTHOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLISHED
- 26 August 2026
- READING TIME
- 17 min read
- TOPIC
- Identity and Access
OpenStack has published OSSA-2026-037 for two Keystone flaws that undermined restrictions on delegated credentials. CVE-2026-80182 allowed a token obtained through an OAuth1 access token, application credential or trust to create new long-lived credentials or further delegations. CVE-2026-80184 allowed a delegated token to enter token-method authentication and, in one case, receive a new token for the owner’s default project rather than the project to which the original application credential was restricted.
Both issues have a CVSS 4.0 score of 7.6 (High). The OpenStack advisory appeared on 25 August and the CVE records entered the 26 August Central European news cycle overnight. Fixes are available for maintained branches. Affected releases run from Keystone 13.0.0 up to versions before 27.0.3, 28.0.3 and 29.0.3. Administrators must not deploy only half the solution: OpenStack says the two patch sets are interdependent.
What delegation means in Keystone
Keystone issues tokens representing identity, scope and authentication methods in an OpenStack cloud. A user can give an application constrained access through an application credential, establish a trust for another user, or use OAuth1. The objective is to avoid sharing a primary password while limiting what automation can do and how long it retains access.
Safe delegation should be monotonic: a derived credential must not gain a broader scope, an independently longer lifetime or authority to create more delegations when its parent did not have that authority. Otherwise a limited token becomes a persistence mechanism. An attacker need not break cryptography or forge a signature; they invoke allowed endpoints in a sequence the policy failed to reject.
These flaws are not anonymous authentication bypasses. CVSS identifies low privileges and an additional attack requirement. The attacker already needs a valid delegated credential. Impact remains serious because these tokens are deliberately given to CI/CD tools, operators, scripts and services whose reach an organisation intended to constrain.
CVE-2026-80182: a constrained token created a successor
Keystone was meant to stop delegated tokens from creating application credentials, managing trusts or authorising the next OAuth1 stage. The restriction was not applied consistently to every delegation method. The advisory gives the example of an OAuth1-scoped token creating an application credential or authorising an OAuth1 request token.
The new credential could persist independently and outlive the token that created it. This breaks the time boundary of incident response. An administrator may revoke the original trust or wait for a short token to expire, while the previously created credential continues to grant access. An identity intended to run one constrained job gains an anchor.
Exposure assessment needs two answers: whether OAuth1, application credentials or trusts are allowed, and whether delegated identities hold roles that can reach guarded endpoints. Finding Keystone in an SBOM is insufficient. Review policy, enabled methods and credential-creation history.
CVE-2026-80184: reauthentication changed the project
The second flaw affects a path where an existing token serves as an authentication method for issuing another token. Delegated tokens originating in OAuth1, application credentials or trusts could enter token-method authentication. When an application-credential token was submitted without explicit scope, Keystone could use the owner’s default project.
If the credential was created for project A while the owner had default project B, the successor token could be scoped to B. This is a context escape rather than a conventional role escalation inside one project. Actual impact depends on the owner’s roles in the default project. If B holds broader resources or administrative rights, the result can cross the intended tenant boundary.
Explicit scope must not be the only protection. The server needs to know that the source method is delegated and cannot be used to reconstruct the primary identity in another scope. The fix centralises method classification and uses it to guard sensitive operations.
Affected releases and the two-part fix
The OSSA lists Keystone >=13.0.0 and <27.0.3, >=28.0.0 and <28.0.3, and >=29.0.0 and <29.0.3. Changes were prepared for 2025.1 Epoxy, 2025.2 Flamingo, 2026.1 Gazpacho and development release 2026.2 Hibiscus. OpenStack distributions may backport patches under their own package versions, so assessment should follow the distribution advisory and patch presence, not only the upstream number.
OpenStack explicitly states that each patch pair is interdependent and must be applied together. One part introduces delegation classification and the [auth] additional_primary_auth_methods option. The other uses that information to guard reauthentication and sensitive operations. Applying the second change without the classification model is not a supported combination.
After the update, any authentication method not built into Keystone is treated as delegated by default. This is a secure fail-closed posture, but it has compatibility consequences. A cloud using a custom or third-party plugin as a primary method must add it to additional_primary_auth_methods. Otherwise legitimate trust, application-credential, OAuth1 and reauthentication flows will be rejected.
Pre-deployment inventory
Start with a list of Keystone regions and endpoints, package versions, distribution vendors and active authentication methods. Identify OAuth1, trusts, application credentials, token-method authentication and every custom plugin. Large clouds may differ between control planes, so one file in an infrastructure repository is not proof of effective state.
Map accounts whose default project differs from the scope of their application credentials. Automation accounts with broad roles in the default project deserve particular attention. Also identify delegated identities that could create credentials, trusts or OAuth1 requests, and whether they created such objects during the parent credential’s lifetime.
Before restart, add legitimate custom primary methods to the new setting and run negative tests. Do not allowlist a plugin merely to restore availability; verify that it truly establishes a primary identity rather than another form of delegation. Incorrect classification recreates the same flaw class in a local extension.
Detection and retrospective analysis
For CVE-2026-80182, search for application-credential, trust or OAuth1 object creation by a token whose method list indicates delegated origin. Build a timeline with parent-token issuance, child-object creation, parent expiry or revocation, and later child use. Activity after the scheduled job ended is especially suspicious.
For CVE-2026-80184, correlate reauthentication without explicit scope with a project_id change between input and output tokens. Compare the application credential’s project with the user’s default project. Detection should account for legitimate refresh automation, but a cross-project result from a delegated method is a high-quality signal.
If abuse is confirmed, blocking the original token is insufficient. Revoke generated application credentials, trusts and OAuth1 tokens, remove unauthorised delegations, rotate reachable service-account credentials, and review activity in Nova, Neutron, Cinder, Glance and Swift. Keystone shows who obtained a token; downstream service logs show what that identity did.
Regression testing after the update
Build a controlled matrix covering a primary password or federation, application credential, trust, OAuth1 and each custom plugin. For each method, test issuance with correct scope, a request without scope, project switching, application-credential creation, trust creation and OAuth1 authorisation. Delegated methods should fail at guarded operations while legitimate primary methods continue to work.
Watch 401/403 rates, method-classification logs and automation-client failures. A canary in one region limits the risk of interrupting CI/CD globally. Once compatibility is confirmed, roll through other control planes, remove temporary exceptions and compare configuration to prevent drift.
The advisory notes that a related weakness in EC2 credential handling is outside OSSA-2026-037 and will be covered separately by an OpenStack Security Note. This update is therefore not evidence that every EC2-compatible credential flow has received equivalent protection.
Source facts and Breachroad conclusions
The two mechanisms, affected releases, CVSS score, patch branches, two-part deployment requirement, additional_primary_auth_methods behaviour and EC2 exclusion come from OSSA-2026-037 and the CVE records. The sources do not report active exploitation. Proposed detection logic, canary order and downstream OpenStack-service analysis are Breachroad conclusions.
Cloud identity and access security training helps teams design safe delegation, while application and infrastructure security assessments can validate effective token scope, Keystone policy and automation paths.
