AI analysis
OpenStack Blazar before 17.0.1 fails to enforce object-level authorization on lease update and delete requests (PUT/DELETE /v2/leases/{lease_id}) because the policy wrapper looks up the target lease under the keyword "lease_id" while the controller names the parameter "id", so the lookup returns None and the ownership check silently falls back to the requesting user's own project_id/user_id. Any authenticated user who knows or obtains another tenant's lease ID can send an update or delete request and bypass the intended ownership check. As a result, an attacker can modify or delete leases (resource reservations) belonging to other users and projects, causing high integrity and availability impact, though no confidentiality loss. All OpenStack clouds running Blazar prior to 17.0.1 are affected. No public proof-of-concept exists, the flaw is not in CISA's KEV catalog, and no exploitation has been reported.
What to do: Upgrade to Blazar 17.0.1 or later. Until patched, restrict PUT/DELETE access on /v2/leases to trusted projects via policy or an API gateway, and audit lease update/delete logs for cross-project modifications. Verify whether your deployment exposes the Blazar V2 API to general tenants.
Affected
| OpenStack Blazar | all versions before 17.0.1 |
Estimated exposure
nichelikely only hundreds to a few thousand Blazar deployments worldwide (optional OpenStack service, authenticated-only API) — Blazar is an optional, lightly-adopted OpenStack resource-reservation service deployed in only a minority of OpenStack clouds, and its API is reachable only by authenticated users rather than anonymous internet scanners.
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
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.