CVE-2026-93854: OpenStack Blazar Auth Bypass Vulnerability

CVE-2026-93854 Overview

CVE-2026-93854 is a broken object-level authorization flaw in OpenStack Blazar before version 17.0.1. The V2 lease API fails to enforce ownership checks on PUT /v2/leases/{lease_id} and DELETE /v2/leases/{lease_id} operations. Any authenticated user who knows a lease identifier can modify or delete leases belonging to other users and projects. The defect maps to [CWE-1025: Comparison Using Wrong Factors] and stems from a parameter-name mismatch inside the policy authorization wrapper. This flaw enables cross-tenant tampering with reservation resources in multi-tenant OpenStack deployments.

Critical Impact
Any authenticated OpenStack user who obtains a lease ID can update or delete leases owned by other projects, breaking tenant isolation for Blazar reservations.

Affected Products

OpenStack Blazar versions prior to 17.0.1
Deployments exposing the Blazar V2 lease API (/v2/leases/{lease_id})
Multi-tenant OpenStack clouds using Blazar for resource reservation

Discovery Timeline

2026-09-18 - CVE-2026-93854 published to the National Vulnerability Database
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93854

Vulnerability Analysis

Blazar is the OpenStack reservation service that lets tenants reserve compute, network, and other resources for future use. The V2 lease API exposes update and delete operations that must confirm the caller owns the target lease before proceeding. Blazar delegates that check to a policy authorize() wrapper, which should load the target lease and build an authorization target from the lease owner's project_id and user_id.

The wrapper never receives the lease. It looks up the record using the keyword argument lease_id, while the controller methods declare the URL parameter as id. The wsme_pecan.wsexpose decorator passes the value positionally, so the keyword lookup returns None. The wrapper falls back to the requesting user's own project_id and user_id as the authorization target, which always satisfies the ownership policy.

The result is a horizontal privilege escalation across projects. An authenticated user with the base member role can issue update or delete requests against any lease ID and bypass tenant isolation. The flaw impacts integrity and availability of reservation state, but does not directly disclose lease contents.

Root Cause

The root cause is a parameter-name mismatch between the policy wrapper and the controller. The wrapper queries the database for lease_id=<value>, but the value is delivered positionally under the name id. The failed lookup silently returns None instead of raising, and the fallback authorization target is derived from the caller rather than the object. This is a broken access control defect and an object-level authorization failure.

Attack Vector

Exploitation requires network access to the Blazar API endpoint and a valid Keystone token for any project. The attacker submits an HTTP PUT or DELETE request to /v2/leases/{lease_id} with a known or guessed lease identifier. The policy check evaluates against the attacker's own identity, passes, and the requested modification or deletion executes against the victim's lease. Lease IDs are UUIDs, so bulk enumeration is impractical, but IDs leaked through logs, support tickets, or integration tooling are sufficient to exploit the flaw.

See the Launchpad Bug Report #2162719 for the upstream defect discussion and code-level details.

Detection Methods for CVE-2026-93854

Indicators of Compromise

Blazar API access logs showing PUT or DELETE requests to /v2/leases/{lease_id} where the requesting X-Project-Id header does not match the owning project of the target lease.
Unexpected lease deletions or state transitions recorded in Blazar's database that cannot be correlated to activity by the lease owner.
Keystone tokens issued to low-privilege project members appearing in Blazar logs immediately before unauthorized lease modifications.

Detection Strategies

Correlate Blazar API request logs with the Blazar database to flag mutations where the caller's project_id differs from the lease project_id.
Enable OpenStack audit middleware (keystonemiddleware.audit) on the Blazar endpoint to capture request subject, action, and target for downstream analysis.
Alert on any lease DELETE or PUT performed by a user account that has never previously interacted with that lease ID.

Monitoring Recommendations

Ship Blazar API, Keystone, and audit logs into a centralized analytics platform and retain them for cross-project correlation.
Baseline normal lease modification patterns per tenant and alert on cross-tenant deviations.
Monitor for spikes in 4xx/5xx responses on /v2/leases/* that may indicate ID enumeration attempts.

How to Mitigate CVE-2026-93854

Immediate Actions Required

Upgrade Blazar to version 17.0.1 or later, which corrects the parameter-name mismatch in the policy authorize() wrapper.
Audit Blazar's database and API logs for unauthorized PUT or DELETE activity against /v2/leases/{lease_id} since the vulnerable code was deployed.
Rotate any lease IDs that may have been exposed in shared logs, tickets, or integrations, and recreate affected reservations if tampering is suspected.

Patch Information

The fix is included in OpenStack Blazar 17.0.1. Operators running earlier 17.x or prior releases should upgrade to 17.0.1 or newer. Refer to the Launchpad Bug Report #2162719 for the upstream commit and backport status across supported OpenStack releases.

Workarounds

Restrict network access to the Blazar API to trusted operators until the patch is applied, using security groups or API gateway policies.
Temporarily disable the V2 lease PUT and DELETE routes at the reverse proxy or WSGI layer if reservation modifications are not required in production.
Tighten policy.yaml for Blazar to require an administrative role for lease update and delete actions until upgrade is complete.

bash

# Example nginx block to deny non-admin access to vulnerable routes
location ~ ^/v2/leases/[^/]+$ {
    limit_except GET POST {
        deny all;
    }
    proxy_pass http://blazar_api;
}