OpenStack Keystone EUVD-2026-66121

The attacker must hold a valid delegated authentication token within the target Keystone deployment - specifically an OAuth1 access token, an application credential token, or a trust-derived token. The Keystone instance must have at least one of these delegation mechanisms enabled, which the advisory confirms is the condition affecting all reported deployments. The attack is triggered by submitting the delegated token to the /v3/auth/tokens endpoint using the token authentication method while omitting any explicit project scope in the request body, causing Keystone to fall back to the credential owner's default project. Limiting factors: (1) the attacker must already be authenticated and hold a valid delegated credential - pure username/password-only environments are not affected; (2) the credential owner must have a default project configured that differs from the credential's intended scope, otherwise the bypass yields no additional access. No administrative or elevated privileges are required beyond possession of a low-privilege delegated credential.

The CVSS 4.0 score of 7.6 with vector AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N is well-calibrated for this flaw: network-reachable and low-complexity, but gated by AT:P indicating the attacker must already hold a valid delegated credential and PR:L confirming authenticated access is required. The high VC and VI scores reflect that a successful attacker can read and modify resources in a project they were never authorized to access, constituting meaningful horizontal privilege escalation in shared cloud environments. No CISA KEV listing and no public exploit code are referenced in the available intelligence, which reduces urgency compared to an actively weaponized flaw; however, the simplicity of the attack path - submitting an existing token with a missing scope field - means that once the behavior is known, exploitation requires little sophistication. EPSS data was not included in the provided intelligence sources, so a probability-of-exploitation estimate cannot be quantified. Multi-tenant OpenStack deployments where application credentials or OAuth1 tokens are issued to external parties, automated pipelines, or cross-team services carry the highest real-world risk, since the credential holder may be a semi-trusted entity exploiting the scope bypass to reach sensitive adjacent projects.

An attacker holding a valid application credential scoped to Project A - obtained legitimately as part of a service account or through credential theft - submits that credential token to the /v3/auth/tokens endpoint using the token authentication method, deliberately omitting the scope field from the request body. Keystone issues a new token scoped to the credential owner's default project (Project B), which the attacker was never authorized to access. The attacker then uses this elevated token to enumerate, exfiltrate, or modify resources in Project B, achieving unauthorized horizontal privilege escalation across project boundaries with no additional steps required.