CVE-2026-93854 in Blazar
Summary
by MITRE • 09/18/2026
In OpenStack Blazar before 17.0.1, the V2 lease API does not enforce object-level authorization on its update and delete operations (PUT /v2/leases/{lease_id} and DELETE /v2/leases/{lease_id}). The policy authorize() wrapper attempts to load the target lease to build the authorization target from its owner, but it looks up the lease under the keyword "lease_id" whereas the controller methods name the parameter "id" (and the wsme_pecan.wsexpose wrapper delivers it positionally). The lookup returns None, and thus authorization falls back to the requesting user's own project_id/user_id instead of the target lease owner. Any authenticated user who knows a lease ID can therefore modify or delete leases belonging to other users and projects, bypassing the intended ownership check.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability in OpenStack Blazar prior to version 17.0.1 represents a critical failure in object-level authorization mechanisms within the V2 Lease API. Specifically, the endpoints responsible for updating and deleting leases, identified as PUT /v2/leases/{lease_id} and DELETE /v2/leases/{lease_id}, fail to correctly validate whether the requesting user has permission to modify or remove resources that do not belong to them. This flaw stems from a mismatch in parameter handling between the API controller methods and the authorization policy wrapper, leading to an unintended bypass of security controls designed to enforce tenant isolation.
The technical root cause lies in how the authorization target is constructed during these operations. The policy authorize() wrapper attempts to load the specific lease resource associated with the request to build a context for checking permissions based on the lease's owner. However, this lookup process relies on identifying the lease using the keyword argument "lease_id". In contrast, the underlying controller methods define the path parameter as "id", and the wsme_pecan.wsexpose wrapper delivers this value positionally rather than by name. Consequently, when the authorization logic attempts to retrieve the target object using the key "lease_id", it fails to find a match because the actual data is stored under the key "id". This results in the lookup returning None instead of the intended lease object.
When the authorization system receives a null value for the target resource, it defaults to a fallback behavior that evaluates permissions based on the requesting user's own project_id and user_id rather than the attributes of the targeted lease. This logic error effectively neutralizes ownership checks because the system no longer compares the requester against the actual owner of the lease being modified or deleted. As a result, any authenticated user who can guess or obtain a valid lease identifier from another tenant is able to execute destructive actions on those resources without authorization.
The operational impact of this vulnerability allows for significant data integrity and confidentiality breaches within an OpenStack cloud environment. An attacker with basic authentication credentials could enumerate lease identifiers through API responses or other side channels and subsequently delete critical infrastructure reservations belonging to other users or projects. This disruption can lead to service outages, resource contention issues, and a complete breakdown of multi-tenant isolation guarantees that are fundamental to private and public cloud deployments. The ability to arbitrarily modify leases also undermines audit trails and billing accuracy associated with reserved resources.
This vulnerability aligns closely with CWE-284, which describes Improper Access Control where insufficient access control leads to unauthorized actions on protected objects. Furthermore, it maps to the MITRE ATT&CK technique T1078, Valid Accounts, as exploitation requires valid credentials but leverages a logic flaw rather than credential theft or privilege escalation in the traditional sense. The attack vector is classified under Remote Code Execution implications via API manipulation, specifically targeting resource management functions.
Mitigation for this issue involves upgrading OpenStack Blazar to version 17.0.1 or later, where the parameter naming inconsistency has been resolved to ensure that the authorization wrapper correctly retrieves the target lease object using the appropriate key. Until an upgrade is performed, administrators should implement strict network-level access controls to restrict API endpoint exposure and monitor for anomalous patterns of lease deletion or modification requests originating from single users targeting multiple distinct project IDs. Additionally, enabling detailed audit logging can help detect exploitation attempts by tracking unauthorized access failures that precede successful bypasses due to the logic error.