How does CVE-2026-71195 allow authenticated users to manipulate OpenStack Manila shares?

The short version

• Any authenticated project member can exploit public shares in vulnerable Manila releases.
• The API fails to re-authorise operations against the actual share owner.
• Affected operations include granting access, revoking rules and creating backups.

The details

OpenStack Manila versions before 23.0.1 contain a critical authorisation flaw, according to the National Vulnerability Database. The issue stems from API controllers that verify permissions against the caller's project context but fail to re-check ownership when loading a foreign public share. This allows any authenticated user to perform actions on shares they do not own. The flaw is rated CVSS 9.9, classifying it as critical severity.

The vulnerability affects specific version ranges: those below 20.0.3, below 21.0.3, below 22.0.2 and below 23.0.1. Chen YuXiang disclosed the issue, which was subsequently documented in advisory OSSA-2026-046. The share UUID is visible because the shares are public, enabling targeted exploitation.

Attackers can grant data-plane read or write access to another tenant's share, according to the NVD record. They can also revoke existing access rules set by the owner or escalate access levels from read-only to read-write. These actions compromise the integrity of the share's access control list.

Further exploitation includes creating backups under the attacker's project, which facilitates data exfiltration. Users can also move foreign shares to the recycle bin or interfere with deletion workflows via restore operations. Export location metadata can be created, updated or deleted by the attacker.

Listing access rules allows the disclosure of sensitive information such as IP addresses, usernames and CephFS keys. This information leakage provides attackers with reconnaissance data for further intrusion attempts within the storage environment.

The context

The flaw was posted to the oss-security mailing list on 20 October 2026 by Goutham Pacha Ravi. The advisory highlights that the API operations do not verify that the caller owns the share before executing changes. The NVD describes the weakness as CWE-863.

Next steps

• Identify all Manila instances running affected versions.
• Review public share configurations for unusual access changes.
• Monitor for backup creation from unexpected projects.
• Plan upgrades to patched versions once available.

What defenders should look for

Teams should monitor Manila API logs for access rule modifications initiated by users outside the share's owning project. Look for backup creation events that do not align with standard maintenance schedules. Check for sudden changes in export location metadata or unexpected moves to the recycle bin. Alert on access listings that reveal sensitive credentials or IP addresses. Isolate affected shares by revoking public status temporarily to contain potential data leakage while investigating the source of the anomalous activity.

What to do and how to stay safe: OpenStack

• Audit all public shares to ensure they are necessary and restrict exposure.
• Implement strict network segmentation to limit lateral movement from compromised shares.
• Monitor API logs for cross-project access attempts and unusual metadata changes.
• Review access control lists regularly to detect unauthorised rule modifications.

Step-by-step guide: How Virtual Patching Works: The Mechanics Behind Inline Protection

General security guidance from the Honeypot Daily newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which OpenStack Manila versions are affected by CVE-2026-71195?

Versions before 20.0.3, before 21.0.3, before 22.0.2 and before 23.0.1 are affected.

What can an attacker do with this vulnerability?

Attackers can grant or revoke access, create backups, delete metadata and expose access rules.

Is there a fix available for this flaw?

The source material indicates versions up to 23.0.1 are affected, implying fixes exist in later versions.