OpenStack Manila EUVD-2026-107046

Requires valid Keystone credentials as an ordinary member of any project/tenant on the cloud (PR:L) - no owner, admin, or cross-tenant trust is needed. The target share MUST be marked public (is_public=True), which is the specific precondition that makes the share's UUID visible to other tenants and routes the request through the vulnerable controllers (allow_access, deny_access, update_access, create_share_backup, soft_delete, restore, export-location metadata, and access-rule listing). Limiting factors that reduce real-world exposure: only public shares are affected (private shares are not in scope), the deployment must be multi-tenant with public shares actually in use, and the running Manila version must be before 23.0.1. No user interaction or non-default protocol is required.

This is a genuine high-priority issue, not a CVSS-inflated one. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) describes trivially-exploitable conditions: any network-reachable, low-privileged authenticated user (a member of ANY project/tenant) can act, with no user interaction and low complexity, and the scope change (S:C) correctly reflects cross-tenant impact. The CWE-863 (Incorrect Authorization) root cause is confirmed by a coordinated OpenStack Security Advisory (OSSA-2026-046) and the oss-security disclosure, which is strong vendor-grade corroboration. No EPSS score was provided in the input, so probabilistic exploitation likelihood cannot be quantified here. The CVE is NOT in CISA KEV and no public POC is referenced, so this is 'no public exploit identified at time of analysis' - however, the vulnerability class (authorization check against the caller's own project instead of the share owner) is conceptually simple to weaponize once the fixed/unfixed code is diffed, so absence of a POC today should not lower urgency much. One signal to note: the attack is only meaningful against shares explicitly marked public, which bounds the blast radius to multi-tenant clouds that actually use public shares. No SSVC decision data was supplied. Net: treat as an urgent patch priority for any multi-tenant OpenStack deployment using Manila with public shares.

On a multi-tenant OpenStack cloud, an attacker with ordinary member credentials in Tenant B discovers the UUID of a public share owned by Tenant A (public share UUIDs are visible to all). They call create_share_backup or list access rules against that share; the API authorizes the call against Tenant B's own context and never re-checks ownership, so the attacker exfiltrates Tenant A's data (including CephFS keys and usernames) or revokes Tenant A's own access. No special attack complexity or user interaction is required, though no public exploit code is referenced.