CVE-2026-93856 in Cinder
Summary
by MITRE • 10/21/2026
In OpenStack Cinder through 29.0.0, cross-project information disclosure can occur in the Messages API. A non-admin user with the project-scoped 'member' or 'reader' role making the Block Storage API v3.3 "List messages" call finds the non-expired user messages for other projects included in the response, resulting in the leakage of UUIDs of resources owned by other projects, in addition to the user message about the other projects' resources (which, by design, are sanitized generic messages). All Cinder deployments are affected.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in OpenStack Cinder versions through 29.0.0 represents a significant cross-project information disclosure flaw within the Block Storage API v3.3 Messages endpoint. This issue specifically affects the List Messages operation, which is designed to return user-facing notifications regarding storage operations such as volume creation or deletion. The core technical failure lies in the backend logic that queries and aggregates these messages without adequately enforcing project-level isolation boundaries for non-administrative users holding member or reader roles. When a user with these scoped permissions invokes the list endpoint, the system fails to filter out message records associated with resources belonging to other projects within the same domain or tenant hierarchy. Consequently, the API response includes not only the expected messages related to the caller's own project but also non-expired messages pertaining to resources in unrelated projects.
The operational impact of this vulnerability is primarily centered on the leakage of internal system identifiers and structural information about the cloud environment. Although the message content itself is sanitized to contain generic, user-friendly text that does not reveal sensitive data such as passwords or private keys, the response payload includes the Universally Unique Identifiers (UUIDs) of resources owned by other projects. In enterprise OpenStack deployments where multiple tenants operate within a shared infrastructure, these UUIDs can serve as valuable reconnaissance artifacts for an attacker. Knowledge of specific resource identifiers allows a malicious actor to potentially target those resources in subsequent API calls if access controls are misconfigured or if additional vulnerabilities exist that allow enumeration based on known IDs. This undermines the fundamental principle of multi-tenancy isolation, where one tenant should have zero visibility into the existence or identity of another tenant's assets unless explicitly granted permission through role-based access control mechanisms.
From a classification perspective, this vulnerability aligns with CWE-200: Exposure of Sensitive Information to an Unauthorized Actor and CWE-613: Insufficient Session Expiration. The failure to restrict data retrieval based on the requesting user's project scope is a classic example of broken object level authorization principles applied at the API layer. In terms of attack vectors, this flaw facilitates reconnaissance activities that are consistent with ATT&CK technique T1087: Account Discovery and potentially T1592: Gather Victim Host Information. An attacker leveraging this vulnerability can map out the resource landscape of other projects without needing elevated privileges or successful exploitation of separate authentication flaws, simply by iterating through list responses to collect valid UUIDs for further probing.
Mitigation strategies must focus on immediate patching and rigorous access control verification. The primary remediation is to upgrade OpenStack Cinder to version 29.0.1 or later, where the backend query logic has been corrected to strictly filter messages based on the project ID associated with the authenticated user's token. Until patches are applied, administrators should audit existing deployments for any custom middleware or API gateways that might inadvertently expose these endpoints without proper filtering. Furthermore, it is advisable to review and tighten role-based access policies to ensure that member and reader roles do not possess unintended privileges across project boundaries. Regular security audits of the Messages API behavior under various authentication scopes can help detect similar logic flaws in other OpenStack services or custom extensions before they are exploited in production environments.