Skip to main content
VulnerabilityPublished Updated

CVE-2026-71195: In OpenStack Manila before 23.0.1, multiple Manila API operations on public shares do not verify that

Source GCVE Database

0
Authoritative record:CVE-2026-71195· Critical 9.9

Not known to be exploited · CVSS 9.9 Critical · fixed in 23.0.1 : patch Manila as a priority.

Data as of 28 Oct 2026, 01:12 UTC

CVSS 3.1 base score
9.9Critical
How severe the flaw is on the 0–10 CVSS scale.
Patch
Available – fixed in 23.0.1, 22.0.2, 21.0.3 +1
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 21 Oct 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade Manila to 23.0.1, 22.0.2, 21.0.3 or 20.0.3.

Affected software

ProductAffectedFixed in
OpenStackManilaAffected
  • >=23.0.0 <23.0.1
Fixed in
  • 23.0.1
OpenStackManilaAffected
  • >=22.0.0 <22.0.2
Fixed in
  • 22.0.2
OpenStackManilaAffected
  • >=21.0.0 <21.0.3
Fixed in
  • 21.0.3
OpenStackManilaAffected
  • >=1.0.0 <20.0.3
Fixed in
  • 20.0.3

Description

In OpenStack Manila before 23.0.1, multiple Manila API operations on public shares do not verify that the caller owns the share. The API controllers authorize operations against the caller's own project context, then load a foreign public share without re-authorizing against the share's actual owner. This affects the following operations: allow_access: grant data-plane read/write access to another tenant's share; deny_access: revoke the owner's existing access rules; update_access: escalate access level (e.g., ro to rw); create_share_backup: exfiltrate share data via a backup created under the attacker's project; soft_delete: move a foreign share to the recycle bin; restore: interfere with the owner's deletion workflow; export location metadata: create, update, and delete metadata on foreign export locations; access rule listing: disclose IPs, usernames, and CephFS keys. Any authenticated project member can exploit these operations on any public share. The share UUID is visible since the share is public.

References

Community reviews

Loading reviews…