Keystone EC2 credential API allows cross-project token scope

TL;DR - Keystone versions 13 through 29 skip ownership validation on POST /v3/credentials for EC2-type credentials. An attacker with an application credential for project A can set project_id to project B, call /v3/ec2tokens, and receive a token scoped to a project they don't own.

What happened

OpenStack Keystone is the identity service at the centre of OpenStack deployments - it issues tokens and enforces multi-tenant authorisation across projects.

CVE-2026-43001 is an authorisation flaw spanning Keystone versions 13 through 29. When a caller creates an EC2-type credential via POST /v3/credentials, Keystone does not check that the supplied project_id matches the project associated with the authenticating application credential. The exploit chain is three steps:

1. An attacker holds an unrestricted application credential for project A. They create an EC2 credential, but set project_id to project B.
2. They perform a /v3/ec2tokens exchange using that credential.
3. Keystone returns a token scoped to project B, still carrying the original app_cred_id.

The attacker now has lateral access to project B within the scope of whatever roles their identity carries - no additional privileges required beyond that initial application credential.

This is a recurring failure mode in identity systems. Ownership and scoping checks around credential-issuance endpoints are easy to overlook, and when they're absent the consequence isn't a single API bug - it's multi-tenant lateral movement.

Who is impacted

• OpenStack deployments running Keystone versions 13 through 29.
• Environments using application credentials together with EC2-style credential flows (/v3/credentials and /v3/ec2tokens).
• Highest risk: multi-project deployments where the same credential owner holds meaningful roles across more than one project and where token scope boundaries are relied on for tenant isolation.

What to do now

• Patch. Apply the latest patched Keystone release for your distribution, including any embedded Keystone shipped inside an OpenStack distro. Inventory versions across all regions and control planes before assuming you're covered.
• Audit credential creation logs for suspicious POST /v3/credentials requests - specifically EC2-type credentials where the supplied project_id differs from the project associated with the calling application credential.
• Audit token exchange logs for /v3/ec2tokens calls that produce tokens scoped to projects inconsistent with the originating application credential.
• If you suspect unauthorised access: rotate all affected application credentials and any derived EC2 credentials. Re-issue least-privilege credentials scoped per project. Don't reuse the compromised credentials.