OpenStack Blazar EUVD-2026-83275

Exploitation requires (1) any valid authenticated OpenStack account with access to the Blazar API (PR:L - not anonymous), (2) a deployment running Blazar before 17.0.1 exposing the V2 lease API, and (3) knowledge of a target lease ID (a UUID that can be obtained or guessed). The limiting factors are the need for a foothold credential on the cloud and the requirement that the operator actually deploys the optional Blazar reservation component; no user interaction, no special non-default configuration, and no elevated privileges are needed once authenticated. The scope is confined to lease objects (modify/delete), not arbitrary code execution.

This is a genuine, high-priority authorization flaw despite the absence of exploitation telemetry. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H, base 7.2) is internally consistent with the description: a network-reachable REST endpoint, no attack requirements, and only a valid low-privilege OpenStack account needed (PR:L). No EPSS score, no CISA KEV listing, and no public POC are provided, so there is no signal of active exploitation - this is a disclosed-but-not-yet-weaponized issue. However, the vulnerability class (broken object-level authorization / IDOR, where the authz target silently falls back to the attacker's own identity) is trivially exploitable with nothing more than curl and a known lease ID, so a low EPSS should not be read as low real risk. Two data-quality caveats: the assigned CWE-1025 ('Comparison Using Wrong Factors') poorly captures the defect, which is really CWE-639/CWE-862 (authorization bypass through a user-controlled key / missing authorization); and the 'Authentication Bypass' tag is misleading because the attacker is fully authenticated - this is an authorization, not authentication, bypass. Confidentiality is correctly rated N since only update/delete are affected, but integrity and availability of other tenants' reservations are directly at stake.

An authenticated OpenStack tenant enumerates or guesses a lease UUID belonging to another project and issues DELETE /v2/leases/{lease_id} or PUT /v2/leases/{lease_id} against the Blazar V2 API. Because the policy target loads under the wrong keyword and resolves to None, the check compares the lease against the attacker's own project_id/user_id and passes, allowing the attacker to cancel or modify reservations they do not own. No public exploit code is identified at time of analysis, but exploitation requires only a standard API call.