Blazar
Monthly
Missing object-level authorization in the OpenStack Blazar V2 lease API allows any authenticated user to modify or delete leases belonging to other users and projects if they know the target lease UUID. The defect affects Blazar releases before 17.0.1 and arises because the oslo.policy authorize() wrapper resolves the wrong request parameter, so the ownership check silently degrades into comparing the requester against their own project_id and user_id and therefore always passes. No public exploit code has been identified at time of analysis, and exploitation requires a valid cloud credential plus a deployment that actually runs the optional reservation service, but the integrity and availability impact on lease objects is high because reservations underpin the scheduled resource allocations of other tenants.
An authenticated user with access to the OpenStack Blazar V2 REST API can enumerate leases belonging to other projects in Blazar versions before 17.0.1, because the GET /v2/leases endpoint enforces neither project scoping nor an administrator-only policy. This broken access control (CWE-862) exposes lease IDs, reservation IDs, resource IDs, and reservation metadata; the leaked lease IDs can then be leveraged with a separate object-level authorization bypass to modify or delete those leases. The flaw requires valid Blazar credentials and a deployment running the optional Blazar reservation service, and no public exploit identified at time of analysis.
Missing object-level authorization in the OpenStack Blazar V2 lease API allows any authenticated user to modify or delete leases belonging to other users and projects if they know the target lease UUID. The defect affects Blazar releases before 17.0.1 and arises because the oslo.policy authorize() wrapper resolves the wrong request parameter, so the ownership check silently degrades into comparing the requester against their own project_id and user_id and therefore always passes. No public exploit code has been identified at time of analysis, and exploitation requires a valid cloud credential plus a deployment that actually runs the optional reservation service, but the integrity and availability impact on lease objects is high because reservations underpin the scheduled resource allocations of other tenants.
An authenticated user with access to the OpenStack Blazar V2 REST API can enumerate leases belonging to other projects in Blazar versions before 17.0.1, because the GET /v2/leases endpoint enforces neither project scoping nor an administrator-only policy. This broken access control (CWE-862) exposes lease IDs, reservation IDs, resource IDs, and reservation metadata; the leaked lease IDs can then be leveraged with a separate object-level authorization bypass to modify or delete those leases. The flaw requires valid Blazar credentials and a deployment running the optional Blazar reservation service, and no public exploit identified at time of analysis.