OpenStack Blazar CVE-2026-93852

Requires a valid authenticated account with access to the Blazar V2 REST API (PR:L); the flaw is present in default configuration of OpenStack Blazar before 17.0.1 because GET /v2/leases enforces neither project scoping nor an admin-only policy, so no special feature toggle or non-default setting is needed. Limiting factors: the attacker must possess (or compromise) working Blazar API credentials for at least one project, and the deployment must actually run the optional Blazar reservation service; the listing itself only discloses lease/reservation/resource IDs and reservation metadata - escalation to modify/delete requires the separate companion object-level authorization bypass.

This is a genuine but moderate broken-access-control (CWE-862 Missing Authorization) flaw, not a high-urgency emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N/VC:H) confirms remote, low-complexity access by an authenticated low-privilege user with no interaction - meaning any tenant with valid Blazar API credentials can reach it against default configurations. However, the impact is over-stated at VC:H: the exposed data is lease/reservation/resource IDs and reservation metadata, i.e. cross-tenant infrastructure metadata rather than credentials or content, so real confidentiality impact is closer to limited. No EPSS score, no CISA KEV listing, and no public exploit are present in the provided data, so there is no evidence of active or automated exploitation - this is a targeted, credentialed-insider or compromised-tenant risk rather than a wormable internet threat. The most material risk is chaining: the description states the enumerated lease IDs feed a COMPANION object-level authorization bypass enabling modify/delete of other tenants' leases, which would raise integrity/availability impact - but that integrity impact belongs to the separate companion CVE, not this listing bug. Note the 'Authentication Bypass' tag is imprecise: this is an authorization (project-scoping/policy) failure, not an authentication bypass; the attacker must already be authenticated (PR:L).

A legitimate but low-privileged tenant user (or an attacker who has compromised any single project's credentials) sends GET /v2/leases to the Blazar REST API and receives every lease across all projects instead of only their own. They harvest lease, reservation, and resource IDs plus reservation metadata for other tenants, mapping the cloud's reserved capacity and then feeding those IDs into the companion object-level authorization bypass to modify or delete other tenants' reservations. No public exploit code is identified at time of analysis; exploitation requires only valid Blazar API access and a single crafted GET request.