In OpenStack Manila before 23.0.1, multiple Manila API operations on public shares do not verify that the caller owns the share.
- Published
- Last modified
- Status
- published
- Known exploitation
- Not listed in CISA KEV
- Fix
- Fixed in 20.0.3, 21.0.3, 22.0.2, 23.0.1
- Public exploit
- None on Exploit-DB
Summary
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.
Affected versions
- OpenStack Manila
From 1.0.0 · fixed in 20.0.3; From 21.0.0 · fixed in 21.0.3; From 22.0.0 · fixed in 22.0.2; From 23.0.0 · fixed in 23.0.1