GHSA-rgvg-xc9j-2jxv
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as low-privilege member/reader tenant user
-
ExploitCall Block Storage API v3.3 'List messages' endpoint
-
ExecutionReceive other projects' non-expired messages and resource UUIDs
-
ImpactCorrelate leaked UUIDs to foreign tenants
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Incorrect resource transfer between spheres
|
| Exploitation Conditions | Requires an authenticated account with a project-scoped 'member' or 'reader' role in the target OpenStack deployment; the attacker then issues the Block Storage API v3.3 'List messages' call (GET /messages). No special or non-default configuration is needed - all Cinder deployments are affected out of the box. Exploitation is time-bounded by the message_ttl option (default 30 days), as only non-expired messages are exposed, and message_reap_interval (default 24 hours) governs cleanup. The practical limiting factor is that the response does not include project_id, so the attacker needs an independent means to correlate each leaked resource UUID to its owning project; disclosed data is restricted to resource UUIDs plus sanitized, by-design generic message strings (no integrity or availability impact). |
| Impact | This is a genuine but moderate-severity multi-tenant isolation flaw rather than a high-urgency emergency. The OpenStack VMT advisory (OSSA-2026-045) confirms all Cinder deployments are affected, and exploitation requires only a low-privilege authenticated tenant account (project-scoped 'member' or 'reader' role) issuing a single Block Storage API v3.3 'List messages' call - low attack complexity, network-reachable. No CVSS vector, EPSS score, KEV listing, or public POC was provided in the input, so probability-of-exploitation signals are entirely absent and cannot be weighed. The realistic impact is bounded: only non-expired user messages (sanitized, by-design generic strings) and resource UUIDs of other projects are leaked, and the advisory explicitly notes the response omits project_id, so an attacker must independently correlate each UUID to its owning project before the leak becomes actionable. There is no integrity or availability impact. Net: a confirmed cross-tenant confidentiality boundary break that matters for multi-tenant/public-cloud operators, but the limited data exposed and the required correlation step keep real-world risk in the medium band. No CVSS vector is present in the source data - the vector below is this analyst's independent assessment and should be verified against the OpenStack advisory/NVD once published. |
| Exploit ScenarioDerived | A legitimate tenant user holding only a 'member' or 'reader' role in an OpenStack cloud calls the Block Storage v3.3 'List messages' endpoint (GET /v3/{project_id}/messages) and receives, alongside their own messages, the non-expired user messages and resource UUIDs belonging to other tenants' projects. The attacker harvests these cross-project UUIDs to map other tenants' resources, though they must separately correlate each UUID to a project since project_id is not returned. No public exploit code is identified; the attack is a single low-complexity authenticated API request. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 20, 2026
Cross-project information disclosure in the OpenStack Cinder Block Storage API (v3.3 'List messages' endpoint) lets any authenticated project-scoped user holding the 'member' or 'reader' role retrieve non-expired user messages that belong to other tenants, leaking resource UUIDs from across the deployment. Every Cinder release from 9.0.0 onward is affected out of the box (fixed in 26.3.1; 27.0.0, 28.0.0 and 29.0.0 remain vulnerable in the published affected range), and no non-default configuration is required to trigger it - the exposure window is simply bounded by message_ttl (default 30 days) and message_reap_interval (default 24 hours). Impact is confidentiality-only and moderate: the response does not carry project_id, so an attacker must independently correlate each leaked UUID to its owning project before it becomes actionable, and the accompanying message text is sanitized generic Action/Detail strings by design. No public exploit code or CISA KEV entry was identified at time of analysis.
RemediationAI
Upgrade Cinder to 26.3.1 or later (or the corresponding patched build of your release branch) using the upstream fixes at https://review.opendev.org/1011490 (2025.1/epoxy), https://review.opendev.org/1011489 (2025.2/flamingo), https://review.opendev.org/1011488 (2026.1/gazpacho), https://review.opendev.org/1011487 (2026.2/hibiscus) and https://review.opendev.org/1011486 (2027.1/indri); note these are Gerrit review links and 26.3.1 is the fixed boundary stated in the advisory, so confirm the tagged patched package for your branch before closing the ticket, and track https://launchpad.net/bugs/2160671 for release announcements. If immediate upgrade is not possible, the highest-value compensating control is to tighten the Block Storage API policy so the messages resource is not readable by project-scoped 'member' and 'reader' roles - for example restrict 'os-services'/'messages' GET rules in cinder's policy.yaml to project_admin or system_admin - accepting the side effect that ordinary tenants lose the asynchronous-operation error feedback that the messages API provides. Reducing message_ttl (default 30 days) and message_reap_interval (default 24 hours) shrinks the exposure window and the volume of leaked UUIDs but does nothing for the underlying authorization bug, and it degrades user-facing diagnostics because messages disappear faster. Reducing the number of accounts holding 'reader'/'member' on shared projects, and alerting on unusual GET /messages call volumes or on a single token enumerating messages far beyond its own project's activity, provides detective coverage for the correlation step an attacker needs; because the response omits project_id, correlating leaked UUIDs with owners requires other data sources, so restricting visibility of project-wide resource listings to the owning project materially raises the exploitation cost. No workaround fully closes the leak short of the patch.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Cinder's user messages subsystem (introduced in the Newton cycle, first shipped in Cinder 9.0.0) exists to tell tenants why asynchronous volume operations failed; internally it is driven by cinder.message.api with strictly pre-defined Action and Detail fields from cinder.message.message_field, deliberately avoiding free-form text so that sensitive data is not exposed through error reporting. Messages are persisted records with an expiry governed by message_ttl (default 30 days) and are reaped on a message_reap_interval (default 24 hours), and end users reach them through GET /v3/{project_id}/messages on the Block Storage REST API, which supports only GET and DELETE. The root cause is a missing project-scoping constraint in the message listing query: the API version 3.3 implementation returns all non-expired messages rather than filtering to the caller's own project, so a low-privileged tenant receives message records (including resource_uuid values) that belong to other projects. This is an object-level authorization / tenant-isolation defect in the same weakness family as CWE-200 (Exposure of Sensitive Information) and broken object-level authorization, although no CWE identifier was assigned in the available data. The mitigating design detail is that the serialized message omits project_id and contains only sanitized generic text, so the leak is a set of orphaned UUIDs rather than a self-describing map of tenants to resources; severity is further shaped by the fact that only unexpired messages are returned, meaning the exposed data set is both time-bounded and continuously shrinking.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Network REST call with low complexity and no user interaction; requires an authenticated member/reader role (PR:L); crosses tenant/project authorization boundary (S:C) but leaks only UUIDs and sanitized messages, so C:L and I:N/A:N.
Primary rating from Vendor (CNA).
CVSS VectorVendor
Lifecycle Timeline
2Description PRE-NVD
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
EUVD-2026-107047
NVD
CVE.org
EPSS
Exploit-DB