CVE-2026-43001: OpenStack Keystone Auth Bypass Vulnerability

CVE-2026-43001 Overview

CVE-2026-43001 is an authorization flaw in OpenStack Keystone affecting versions 13 through 29. The POST /v3/credentials endpoint fails to validate that the caller-supplied project_id for an EC2-type credential matches the project of the authenticating application credential. An attacker holding an unrestricted application credential for project A can create an EC2 credential targeting project B. A subsequent /v3/ec2tokens exchange then issues a Keystone token scoped to project B while still carrying the original app_cred_id. This enables cross-project lateral movement within the credential owner's role footprint and maps to CWE-863: Incorrect Authorization.

Critical Impact

An attacker with a valid application credential in one project can pivot into other projects where the credential owner holds roles, bypassing project isolation boundaries in OpenStack identity services.

Affected Products

• OpenStack Keystone version 13
• OpenStack Keystone versions 14 through 28
• OpenStack Keystone version 29

Discovery Timeline

• 2026-05-01 - CVE-2026-43001 published to NVD
• 2026-05-04 - Last updated in NVD database

Technical Details for CVE-2026-43001

Vulnerability Analysis

The vulnerability resides in Keystone's credential creation handler. The POST /v3/credentials endpoint accepts a project_id parameter when creating EC2-type credentials. Keystone does not enforce that this project_id matches the project scope of the application credential used to authenticate the request.

Application credentials in OpenStack are intended to bind delegated authority to a specific project. The missing project-scope check breaks this binding for the EC2 credential creation path. An authenticated caller can therefore mint EC2 credentials referencing any project the credential owner has roles in.

The second stage of exploitation uses /v3/ec2tokens. Exchanging the malicious EC2 credential yields a Keystone token scoped to the targeted project. The issued token retains the original app_cred_id, allowing an attacker to operate against project B's resources while masquerading under the credential identity of project A.

Root Cause

The root cause is missing authorization logic [CWE-863]. The credential creation endpoint trusts the client-supplied project_id field without comparing it against the authenticated principal's application credential project scope. This is a design oversight in the EC2 credential issuance path rather than a memory-safety defect.

Attack Vector

Exploitation requires network access to the Keystone API and possession of an unrestricted application credential. The attacker submits a crafted POST /v3/credentials request specifying type: ec2 and a project_id belonging to a different project where the credential owner holds roles. The attacker then calls /v3/ec2tokens with the resulting access key and secret to receive a project-B-scoped Keystone token. From that point, the token authorizes any action permitted by the owner's roles on project B, including compute, storage, and network operations.

No verified public proof-of-concept code is available. Refer to the
Launchpad bug report and the OpenDev review for technical specifics:
 - https://bugs.launchpad.net/keystone/+bug/2149775
 - https://review.opendev.org/c/openstack/keystone/+/985804

Detection Methods for CVE-2026-43001

Indicators of Compromise

• Keystone audit log entries showing POST /v3/credentials requests where the supplied project_id differs from the authenticating application credential's project scope.
• /v3/ec2tokens exchanges that produce tokens scoped to a project different from the originating application credential's project.
• Tokens carrying an app_cred_id whose project scope diverges from the token's project scope.
• Unexpected resource access in tenant projects where the actor was not previously active.

Detection Strategies

• Correlate app_cred_id values across token issuance events to identify a single application credential producing tokens for multiple projects.
• Parse Keystone access logs for credential creation events and compare the request's project_id field against the issuing principal's project context.
• Alert on EC2 credential objects whose project_id does not match the project of the application credential that created them.

Monitoring Recommendations

• Forward Keystone API logs and CADF audit events to a centralized logging platform for cross-project correlation.
• Track creation and use of EC2 credentials with dashboards segmented by project, principal, and app_cred_id.
• Monitor for sudden role expansion or new resource access patterns by application credential identities.

How to Mitigate CVE-2026-43001

Immediate Actions Required

• Apply the Keystone patch from the OpenDev review once merged into your supported branch.
• Inventory existing application credentials and revoke any that are unrestricted and not strictly required.
• Audit existing EC2 credentials for project scope mismatches against their parent application credentials and revoke anomalous entries.

Patch Information

The upstream fix is tracked in OpenDev change 985804 and the Launchpad bug report 2149775. The patch enforces that the project_id supplied during EC2 credential creation matches the project scope of the authenticating application credential. Operators running Keystone 13 through 29 should backport the change or upgrade to a fixed release once published by their distribution.

Workarounds

• Mark application credentials as restricted (unrestricted: false) to prevent them from creating additional credentials.
• Apply Keystone policy overrides that deny identity:create_credential to application-credential-scoped tokens until the patch is deployed.
• Limit role assignments so that a single user does not hold roles across sensitive projects, reducing the blast radius of any cross-project pivot.

# Example: enforce restricted application credentials when issuing
openstack application credential create my-app-cred \
  --role member \
  --restricted

# Example policy.yaml override to deny credential creation via app creds
# Place in /etc/keystone/policy.yaml
"identity:create_credential": "rule:admin_required and not application_credential"