CVE-2026-80184: OpenStack Keystone Auth Bypass Vulnerability

CVE-2026-80184 Overview

CVE-2026-80184 is an authorization flaw in OpenStack Keystone versions before 29.0.3. Tokens obtained through delegated authentication mechanisms including OAuth1 access tokens, application credentials, and trusts can be submitted to the token-method authentication path for reauthentication. This reauthentication path allows the token to escape its intended project scope. When an application credential token is presented without an explicit scope, Keystone issues a new token scoped to the credential owner's default project rather than the project the credential was issued for. The bypass affects all Keystone deployments that permit delegated authentication through OAuth1, application credentials, or trusts. The weakness is classified under CWE-863: Incorrect Authorization.

Critical Impact
An authenticated actor holding a delegated credential can obtain a token scoped to a project outside the intended delegation boundary, breaking tenant isolation.

Affected Products

OpenStack Keystone versions prior to 29.0.3
Keystone deployments permitting OAuth1 access tokens
Keystone deployments permitting application credentials or trusts

Discovery Timeline

2026-08-25 - CVE-2026-80184 published to NVD
2026-08-26 - Last updated in NVD database

Technical Details for CVE-2026-80184

Vulnerability Analysis

OpenStack Keystone supports several delegated authentication mechanisms that issue tokens bound to a narrower scope than the credential owner's full authorization. Application credentials are typically issued for a specific project, OAuth1 access tokens delegate a subset of a user's roles, and trusts allow a trustor to delegate authorization to a trustee for a defined project.

The vulnerability arises when a token derived from any of these mechanisms is resubmitted to Keystone using the token authentication method to obtain a new token. Keystone's reauthentication path does not consistently enforce that the resulting token remains within the delegated scope. Application credential tokens presented without an explicit scope parameter receive a new token scoped to the credential owner's default project, which may differ from the project the application credential was created for.

The result is a horizontal scope escape. A trustee, OAuth consumer, or application credential holder can obtain tokens that operate against projects outside the boundary the delegating principal intended.

Root Cause

The root cause is incorrect authorization logic in Keystone's token-method reauthentication path. Scope enforcement relies on the requester supplying an explicit scope, and the fallback behavior defaults to the owner's project rather than rejecting the request or preserving the original delegated scope. Keystone treats the presented token as a general-purpose credential rather than a scope-restricted delegation.

Attack Vector

An attacker requires a valid delegated token. This can be an OAuth1 access token, an application credential token, or a trust-scoped token obtained through legitimate means or theft. The attacker then submits the token to Keystone's identity API using the token authentication method, omitting or manipulating the scope field. Keystone responds with a new token whose project scope exceeds the original delegation. The request is a standard authenticated call over the network to the Keystone endpoint.

Refer to the OpenStack Security Advisory OSSA-2026-037 and the Launchpad Keystone Bug Report for exploitation specifics.

Detection Methods for CVE-2026-80184

Indicators of Compromise

Keystone audit log entries showing token issuance where the resulting project scope differs from the original delegated credential's project.
Application credential authentication events submitted to the token method without an explicit scope parameter.
Repeated reauthentication requests from the same OAuth1 consumer or trustee producing tokens across multiple projects.

Detection Strategies

Parse Keystone logs for POST /v3/auth/tokens events where methods includes token and the source token originated from application_credential, oauth1, or trust methods.
Correlate the project ID recorded on the source delegated token with the project ID of the newly issued token and alert on mismatches.
Baseline expected reauthentication behavior per service account and flag deviations that widen scope.

Monitoring Recommendations

Enable Keystone's CADF audit notifications and forward them to a centralized SIEM for continuous review.
Monitor API gateway logs for calls to /v3/auth/tokens that chain multiple authentication method transitions.
Track application credential usage patterns and alert on tokens invoked against projects other than the credential's issued project.

How to Mitigate CVE-2026-80184

Immediate Actions Required

Upgrade OpenStack Keystone to version 29.0.3 or later across all controller nodes.
Rotate application credentials, OAuth1 access tokens, and trust delegations that may have been used against unpatched Keystone instances.
Review Keystone audit logs since deployment for reauthentication events that produced tokens outside the delegated project scope.

Patch Information

The fix is delivered in OpenStack Keystone 29.0.3. See OpenStack Security Advisory OSSA-2026-037 and the OpenWall OSS-Security Discussion for backport availability across supported Keystone releases. Apply distribution packages that incorporate the upstream patch referenced in the Launchpad Bug Report.

Workarounds

Disable OAuth1, trusts, and application credential authentication methods in keystone.conf if they are not required by workloads.
Restrict application credential creation to service accounts that do not hold roles on projects beyond the intended delegation target.
Require explicit scope on all application credential authentication requests through API policy enforcement until the patch is deployed.

bash

# Configuration example: disable delegated auth methods pending patch
# /etc/keystone/keystone.conf
[auth]
methods = password,token
# Remove: oauth1, application_credential, and trust from methods
# Restart the Keystone service after applying changes
systemctl restart apache2  # or the wsgi service hosting Keystone