Disclosure: this page contains affiliate links. East Bay Cyber may earn a commission if you buy through them, at no extra cost to you. That never changes how we rank products. Editorial policy.
CVE-2026-71195: OpenStack Manila Flaw
TL;DR - CVE-2026-71195 is a CVSS 9.9 authorization flaw in OpenStack Manila. - Authenticated project members may affect other tenants’ public shares and export-location metadata. - Upgrade to Manila 23.0.1 or later, apply the branch patch, and audit API activity.
Vulnerability at a Glance
| Field | Assessment |
|---|---|
| CVE ID | CVE-2026-71195 |
| CVSS | 9.9 critical |
| CVSS vector | Not provided in the supplied NVD data; obtain it directly from the NVD record |
| Attack vector | Network-accessible Manila API |
| Authentication required | Yes, an authenticated project member |
| Privileges required | Project-member access; exact CVSS privilege value is not confirmed without the vector |
| Affected component | OpenStack Manila Shared File Systems service |
| Patch available | Yes |
| Fixed threshold | Manila 23.0.1, with branch-specific OpenStack patches also available |
| CISA KEV | No, on_kev: false |
| In-the-wild exploitation | Not confirmed |
CVE-2026-71195 is a cross-project authorization failure in Manila. The issue matters most in environments that expose or use public shares because authenticated users may be able to see public-share identifiers. An attacker may not need to guess a private object identifier to target a public share.
The vulnerability can affect confidentiality, integrity, and availability. Depending on the operation and storage backend, an attacker may change access rules, disclose access-rule information, create a backup under another project, alter export-location metadata, or interfere with deletion workflows.
For broader context on security controls and risk management, see this cybersecurity framework glossary.
What Is This Vulnerability?
The root cause is an authorization-context mismatch. Manila validates the caller in the context of the caller’s project, then uses a caller-supplied share or export-location UUID to load an object. The affected code paths do not consistently verify that the requested object belongs to the caller’s project before performing the operation.
A project member can therefore potentially operate on a public share owned by a different tenant. Affected operations include allow_access, deny_access, and update_access, which can grant, revoke, or modify access rules. The issue also affects create_share_backup, soft_delete, restore, access-rule listing, and operations involving export-location metadata.
The advisory describes a related export-location authorization problem. In that path, the metadata lookup is not properly scoped to the share identified in the request. An authenticated project member may supply an export-location UUID together with a share identifier they control and then read, modify, or delete metadata belonging to another project. That creates a risk of connection-information disclosure and operational disruption.
Who Is Affected?
The OpenStack advisory identifies these affected Manila version ranges:
| Affected release range | Status |
|---|---|
>=1.0.0, <20.0.3 |
Affected |
>=21.0.0, <21.0.3 |
Affected |
>=22.0.0, <22.0.2 |
Affected |
==23.0.0 |
Affected |
The NVD description summarizes the issue as affecting OpenStack Manila before 23.0.1. Administrators should use the branch-specific advisory and package metadata to determine the correct update for a distribution or deployment method. The fixed threshold should not be read as proof that every packaging system labels its package exactly 23.0.1.
Risk is highest where public shares are enabled, authenticated project members can reach the Manila API, and the storage backend applies access-rule changes to existing shares. Deployments that use export-location metadata, backups, or CephFS-related access information should treat the issue as a priority. Even if public shares are not widely advertised, administrators should verify whether they are enabled and whether historical public-share objects remain accessible.
Analyst’s Take: Upgrade priority should be driven by exposure, not by the absence of confirmed in-the-wild exploitation. Public shares and authenticated multi-tenant API access provide the conditions this flaw abuses, while the affected operations can expose metadata, change access, or disrupt share workflows. Where an immediate upgrade is not possible, restrict public-share functionality and review API activity, but treat those steps as temporary controls.
CVSS Score Breakdown
CVE-2026-71195 has a reported CVSS base score of 9.9, placing it in the critical category. The score indicates that the vulnerability can have severe impact and can be reached through a network service, but the supplied NVD response does not include the CVSS vector string.
Because the vector is unavailable in the supplied material, individual metric values such as attack complexity, privileges required, user interaction, scope, and the confidentiality, integrity, and availability impacts should not be reconstructed from the numeric score. The fact that authentication is required does not, by itself, establish the exact CVSS PR value. Obtain the authoritative vector from the NVD record before importing the score into compliance systems or risk registers.
Operationally, the high severity is supported by the range of possible outcomes. Unauthorized access-rule changes can affect data-plane access, backup creation can create an exfiltration path, access-rule listing can disclose IP addresses, usernames, or CephFS keys, and deletion-related operations can disrupt another tenant’s share lifecycle.
Exploitation Status
The available material confirms a viable authenticated attack path and provides enough technical detail for defenders to understand the affected operations. It does not identify a public exploit repository or confirm active exploitation in the wild. The current assessment is therefore: public technical details are available, an authenticated exploit path is known, a public PoC repository has not been identified in the supplied sources, and in-the-wild exploitation is not confirmed.
CVE-2026-71195 is not currently listed in the CISA Known Exploited Vulnerabilities catalog. That status does not show that exploitation is impossible. It means the available CISA lookup returned on_kev: false; it does not eliminate the need to investigate exposed Manila deployments, especially where public shares and multi-tenant access are in use.
How to Detect It
Detection should focus on authenticated users performing operations against shares or export locations outside their project context. Review Manila API logs for the affected operations, correlate the authenticated project or tenant identifier with the target share owner, and prioritize events involving public shares. A successful request is not required to indicate attempted exploitation; repeated 404, 403, or unusual object-lookup failures may also be useful signals when they occur across many UUIDs.
Inspect for unexpected access-rule changes, newly created backups, export-location metadata modifications, and restore or soft-delete events. Look for activity from project members who do not normally administer shared file systems, unusual source addresses, and bursts of requests against multiple public-share UUIDs.
Technical Notes
The exact log format varies by OpenStack deployment and API service configuration. A basic search for affected operation names can help establish an initial scope:
sudo grep -E \
'allow_access|deny_access|update_access|create_share_backup|soft_delete|restore|export[-_ ]location|access[-_ ]rules' \
/var/log/manila/*.log
For centralized logs, adapt the query to the fields used by the deployment. A generic example for a structured logging platform is:
service="manila"
AND (
action IN ("allow_access", "deny_access", "update_access",
"create_share_backup", "soft_delete", "restore")
OR path CONTAINS "/export_locations"
OR path CONTAINS "/access"
)
The strongest detection signal is a mismatch between the authenticated project and the owner project of the target share or export location. If Manila logs do not record both values, correlate API records with the Manila database, audit middleware, Keystone request context, or cloud controller records. Preserve request IDs, user IDs, project IDs, target UUIDs, HTTP methods, response codes, and timestamps.
Mitigation and Patching
Upgrade affected deployments to the vendor-provided fixed release. The NVD identifies Manila 23.0.1 as the fixed threshold. The OpenStack advisory also provides branch-specific security patches for 2025.1 Epoxy, 2025.2 Flamingo, 2026.1 Gazpacho, 2026.2 Hibiscus, and the 2027.1 Indri development branch. Apply the patch appropriate to the deployed branch rather than copying a patch intended for a different release line.
If patching cannot be completed immediately, temporarily restrict or disable public-share functionality where operationally feasible. Review project-member permissions and reduce access to the Manila API to trusted administrative or service networks. These measures reduce exposure but do not correct the authorization flaw and should not replace the upgrade.
When managing emergency updates, use a dedicated password manager and separate administrative credentials from ordinary user accounts. Teams evaluating that workflow can review 1Password as one available option.
Technical Notes
For a source or Python virtual-environment deployment, an example upgrade command is:
python -m pip install --upgrade 'manila>=23.0.1'
Production operators using distribution packages, Kolla, OpenStack-Ansible, containers, or another deployment framework should use that framework’s package update process and verify that the resulting Manila package contains the vendor fix. The OpenStack review changes associated with the advisory are:
- 2025.1 / Epoxy: https://review.opendev.org/1011483
- 2025.2 / Flamingo: https://review.opendev.org/1011482
- 2026.1 / Gazpacho: https://review.opendev.org/1011481
- 2026.2 / Hibiscus: https://review.opendev.org/1011479
- 2027.1 / Indri: https://review.opendev.org/1011478
After updating, restart the Manila API and related services according to the deployment architecture, then run a controlled authorization test. A cross-project request for a foreign share or export location should be rejected, with the companion Tempest changes expecting HTTP 404 for the relevant export-location authorization cases.
Treat potentially exposed data as compromised until reviewed. Audit and, where appropriate, rotate CephFS keys, revoke unauthorized share access rules, inspect backups created by unexpected projects, and review export-location metadata for connection details. Preserve evidence before cleanup if incident response or legal requirements apply.
For longer-term remediation, align authorization testing with secure-by-design principles so that object ownership is verified consistently across every API operation.
References
The authoritative NVD record is available at https://nvd.nist.gov/vuln/detail/CVE-2026-71195. Use it to verify the current CVSS vector, affected-product data, and any subsequent updates to the record.
The OpenStack advisory is OSSA-2026-046: https://security.openstack.org/ossa/OSSA-2026-046.html. Additional disclosure and tracking material is available through the Openwall oss-security copy at https://openwall.com/lists/oss-security/2026/10/20/18, Launchpad bug https://launchpad.net/bugs/2161412, and the related Manila issue at https://bugs.launchpad.net/manila/+bug/2161412.
The OpenStack review links for the branch fixes are listed above. The related Tempest test update is available at https://review.opendev.org/1011484. CISA KEV status can be checked at https://www.cisa.gov/known-exploited-vulnerabilities-catalog.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.