CVE-2026-93852 in Blazar
Summary
by MITRE • 09/18/2026
In OpenStack Blazar before 17.0.1, the V2 lease listing operation (GET /v2/leases) returns leases for every project without enforcing project scoping or an administrator-only policy. Any authenticated user with access to the Blazar REST API can enumerate leases belonging to other tenants, exposing lease IDs, reservation IDs, resource IDs, and reservation metadata. The exposed lease IDs also enable the object-level authorization bypass tracked in the companion request, allowing an attacker to then modify or delete the enumerated leases.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in OpenStack Blazar prior to version 17.0.1 represents a critical failure in access control mechanisms within the cloud resource management service. Specifically, the V2 lease listing endpoint exposed via GET /v2/leases fails to enforce proper project scoping or administrator-only policy restrictions. This architectural flaw allows any authenticated user who possesses valid credentials for the Blazar REST API to query and retrieve data associated with all projects in the environment, rather than being restricted solely to their own tenant context. The absence of these enforcement mechanisms means that the service does not validate whether the requesting entity has authorization to view resources belonging to other tenants, leading to a severe breach of multi-tenancy isolation principles fundamental to cloud infrastructure security.
The operational impact of this flaw is significant as it enables unauthorized enumeration of sensitive lease information across all projects in an OpenStack deployment. An attacker can harvest lease IDs, reservation identifiers, resource IDs, and detailed metadata regarding reservations made by other tenants. This exposure provides a comprehensive view of the computational resources allocated to various teams or organizations within the cloud environment. Beyond mere data leakage, this vulnerability facilitates further malicious activities because the exposed lease identifiers serve as direct references to specific resource allocations. The attacker can leverage these enumerated values to target individual leases for subsequent actions, effectively bypassing object-level authorization checks that should normally restrict modification and deletion operations to authorized owners or administrators only.
From a classification perspective, this issue aligns with CWE-284 Improper Access Control, as the application fails to enforce proper restrictions on authenticated users regarding access to specific objects. It also corresponds to CWE-601 URL Redirection to Untrusted Site in terms of logic flow if redirection were involved, but more accurately fits CWE-798 Use of Hard-coded Credentials or CWE-200 Exposure of Sensitive Information to an Unauthorized Actor depending on the exact data sensitivity. In the context of the MITRE ATT&CK framework for cloud environments, this vulnerability supports reconnaissance activities by allowing adversaries to map out resource allocations and identify high-value targets within the infrastructure. The ability to enumerate resources is a precursor step that significantly lowers the barrier for subsequent exploitation attempts such as unauthorized modification or deletion of critical lease records.
To mitigate this risk, organizations running OpenStack Blazar must upgrade immediately to version 17.0.1 or later where these access control checks have been properly implemented and enforced. Until an upgrade is feasible, administrators should consider implementing network-level controls or reverse proxy configurations that restrict access to the /v2/leases endpoint based on IP whitelisting if possible, although this is a less robust solution than fixing the underlying code logic. It is also advisable to audit existing lease data for any signs of unauthorized enumeration and review API gateway logs to detect patterns indicative of mass leasing queries from single sources. Ensuring that all OpenStack services adhere strictly to project-scoped access policies during development and deployment phases will prevent similar vulnerabilities in future releases.