Summary
- CVE-2026-71195 covers authorisation failures affecting public file shares and export-location metadata in OpenStack Manila.
- The weaknesses could allow cross-project changes to share permissions, metadata or share management operations, depending on the storage backend.
- Corrective changes have been published for maintained OpenStack branches, with exposure dependent on the functions used by each deployment.
The OpenStack security team has disclosed authorisation vulnerabilities in its Manila file storage service that could allow an authenticated user to interfere with storage resources belonging to another cloud project.
The weaknesses, published on 20 October under security advisory OSSA-2026-046 and CVE-2026-71195, affect operations involving public file shares and the metadata associated with storage export locations.
In some configurations, users could alter access rules on shares they did not own, initiate unauthorised share management operations or read, change and delete metadata belonging to another project.
The consequences depend on the functions enabled in the deployment and the behaviour of the underlying storage backend. OpenStack has published corrective changes across maintained release branches, although the advisory does not identify confirmed malicious exploitation.
Public visibility did not preserve administrative boundaries
Manila provides shared file systems within OpenStack cloud environments, allowing projects to provision and manage storage through a common control plane and supported storage backends.
Projects are used to group resources and control which identities may administer them. Multiple teams or customers can therefore use the same broader cloud environment while retaining separate authority over their own services and data.
Public shares introduce a distinction between the ability to discover or access a resource and the authority to change its configuration.
A share may be made public for legitimate operational reasons without giving every authenticated project member permission to modify its access rules or initiate administrative operations.
The first vulnerability group identified in the advisory failed to preserve that distinction.
Chen YuXiang of the Chinese Academy of Sciences’ Institute of Computing Technology reported that a user who did not own a public share could modify its access rules and export-location metadata.
Subsequent research by Red Hat’s Goutham Pacha Ravi and Carlos da Silva identified additional paths involving backups, soft deletion and restoration of public shares belonging to other projects.
These operations have different operational consequences. Changing an access rule may alter which systems or users can reach a file share, while a deletion or restoration operation can affect its availability or administrative state.
Where the underlying storage backend supports the affected operation, an unauthorised request may result in a real configuration change rather than merely producing an incorrect API response.
The advisory specifically notes the possibility that changes to existing access rules could disrupt access for the share owner or other authorised users.
A second weakness involved export-location metadata
The investigation also identified a separate failure in the API handling metadata associated with export locations.
Export locations describe how clients can reach a shared file system through its supported storage protocol or backend. Metadata attached to those locations can contain information used to describe or manage the connection.
The affected API did not adequately restrict a metadata lookup to the share identified in the request.
As a result, an authenticated project member could provide the identifier of a share they controlled while referencing an export-location metadata record associated with another project.
The vulnerable service could then allow the caller to read, modify or delete that external record.
Unlike the first group of weaknesses, this issue is not confined to the administrative operations of public shares. The advisory states that deployments using export-location metadata are affected, although the issue can be easier to exploit where public shares exist.
The distinction matters when assessing storage environments that do not deliberately expose shares across project boundaries.
Such a deployment may avoid some public-share management risks while still using the metadata functionality implicated in the separate authorisation failure.
The advisory does not establish that every metadata record exposes confidential customer files. Its confirmed finding concerns unauthorised access to metadata and the possibility of modification or deletion.
Tenant isolation relies on ownership checks
OpenStack users authenticate before accessing cloud management services, but an authenticated identity is not necessarily authorised to administer every resource reachable through those services.
Each operation must establish the caller’s permissions in relation to the specific object being requested.
In the Manila cases, that requirement was not consistently enforced when a share had public visibility or when a metadata identifier was supplied alongside the identifier of another share.
The resulting weakness crosses the expected administrative boundary between projects.
In environments serving several organisations, those boundaries support separation of customers, departmental workloads and applications with different access requirements.
An authorisation failure at the management API can therefore affect resources outside the requesting user’s own project even where the underlying file systems are otherwise operating correctly.
Whether the failure leads to interruption, exposure of metadata or changes to storage permissions depends on the affected operation and how the storage backend processes it.
The research does not provide evidence of a broader compromise of the OpenStack control plane or establish that attackers have obtained unrestricted access to the contents of every affected share.
Corrective changes cover maintained releases
The vulnerability affects Manila versions from 1.0.0 before 20.0.3, versions 21.0.0 before 21.0.3, versions 22.0.0 before 22.0.2 and version 23.0.0.
OpenStack has published patches for its Epoxy, Flamingo, Gazpacho and Hibiscus release branches, alongside a corresponding change for the development branch.
These fixes address the authorisation checks governing public-share operations and export-location metadata access.
The companion Manila Tempest test update also changes the expected result for cross-project export-location requests, requiring the corrected service to reject the unauthorised lookup with a not-found response.
That test provides a means of checking whether the API correctly prevents a caller from referring to metadata outside the share for which authorisation has been established.
Cloud operators must match the security changes to their deployed Manila release and distribution. The presence of a patch in a maintained upstream branch does not establish that every downstream package or managed deployment has already received it.
OpenStack’s 20 October advisory identifies the affected version ranges, relevant functionality and patch references, while leaving the extent of any real-world exploitation unconfirmed.
