OpenStack Manila corrige fallos que permitían operar sobre shares de otros proyectos

OpenStack publicó correcciones para CVE-2026-71195, un fallo de autorización en Manila, su servicio de archivos compartidos. En despliegues afectados, una persona autenticada como miembro de un proyecto podía cambiar ciertas reglas y operaciones de un share perteneciente a otro proyecto. El problema no daba acceso anónimo al servicio: cruzaba la frontera entre proyectos después de que el atacante tuviera una cuenta válida en el cloud.

El alcance depende de dos funciones. Los despliegues con shares públicos podían exponer operaciones de administración sobre recursos ajenos; los que usan la API de metadatos de ubicación de exportación podían quedar expuestos a una segunda ruta. OpenStack publicó el aviso OSSA-2026-046 el 20 de octubre y asignó el identificador CVE al fallo. El aviso no informa de explotación activa ni de incidentes confirmados en instalaciones concretas.

-SecureCrew dice: “público” describe quién puede ver un recurso; no debería convertir a cada proyecto vecino en su administrador.-

La visibilidad del share no cambia a su propietario

En Manila, un share es un recurso de almacenamiento de archivos que un proyecto puede presentar a clientes mediante el backend configurado. Marcarlo como público permite que otros proyectos lo vean o accedan a él según las reglas del servicio, pero no les transfiere la propiedad. El defecto permitió que la API tratara algunas solicitudes de modificación como autorizadas sin verificar que el proyecto solicitante fuera dueño del share objetivo.

Entre las operaciones afectadas, un miembro no propietario podía cambiar reglas de acceso, crear un backup y eliminar temporalmente o restaurar un share público de otro proyecto. El equipo de seguridad de OpenStack también señala que un backend compatible podía aplicar cambios no autorizados a reglas existentes. Eso podría interrumpir el acceso del propietario o de sus usuarios autorizados, aunque el advisory no afirma que todos los backends ejecuten de la misma forma cada cambio.

-SecureCrew dice: compartir el acceso al almacenamiento no debería compartir también el botón de “borrar”; esa diferencia tiene que sobrevivir hasta el controlador de la API.-

Otra ruta afectaba a los metadatos de exportación

El fallo separado estaba en la API de metadatos de ubicación de exportación, información que Manila asocia con el modo en que el backend presenta o localiza un share. La búsqueda no limitaba correctamente la ubicación al share mencionado en la petición. Un miembro autenticado podía proporcionar el UUID de una ubicación ajena junto con el identificador de un share que sí controlaba para leer, modificar o borrar esos metadatos.

OpenStack indica que esta segunda ruta es más fácil de aprovechar cuando hay shares públicos, y considera afectados también los despliegues que usan esos metadatos. No equivale a que el atacante reciba automáticamente el contenido de los archivos: el aviso describe operaciones de control y metadatos, y advierte de una posible alteración del acceso cuando el backend aplica reglas cambiadas. La distinción importa al revisar registros: una llamada a la API vulnerable no demuestra por sí sola que los datos se leyeran o exfiltraran.

-SecureCrew dice: un UUID identifica un objeto; no es una autorización portátil para consultarlo desde cualquier otro objeto.-

Ramas afectadas y comprobaciones para operadores

OpenStack lista Manila anterior a 20.0.3, las versiones 21.0.0 a 21.0.2, 22.0.0 a 22.0.1 y 23.0.0 como afectadas. Las correcciones están publicadas como cambios para las ramas 2025.1/Epoxy, 2025.2/Flamingo, 2026.1/Gazpacho y 2026.2/Hibiscus; también hay una propuesta para la rama de desarrollo 2027.1/Indri. Son referencias de rama y cambios de código, no una instrucción para instalar el nombre de una release como si fuera un paquete listo para cualquier distribución.

El equipo que opera Manila debe identificar la versión y el estado del parche en sus paquetes, revisar si tiene shares públicos y determinar si sus flujos utilizan metadatos de ubicaciones de exportación. Las distribuciones pueden incorporar correcciones mediante backports, así que una versión upstream antigua no confirma por sí sola que un paquete siga expuesto. En sentido inverso, que una rama tenga el cambio publicado tampoco demuestra que ya esté desplegado en producción.

El identificador CVE permite seguir el aviso y coordinar el inventario, pero no sustituye la revisión de configuración y autorización efectiva. Conviene priorizar la corrección donde se usen las rutas afectadas y comprobar los registros de operaciones sobre shares y metadatos durante el periodo vulnerable. OpenStack no atribuye actividad maliciosa observada; cualquier investigación de acceso indebido debe apoyarse en la telemetría de cada instalación, no en el mero anuncio del fallo.

Diccionario de la Crew

CVE-2026-71195 — Identificador del fallo de autorización de Manila descrito en el aviso OSSA-2026-046.

Manila — Servicio de OpenStack que gestiona recursos compartidos de sistemas de archivos.

Share — Recurso de archivos que Manila presenta mediante un backend de almacenamiento.

Share público — Share visible o accesible desde otros proyectos según las reglas de Manila; no transfiere su propiedad.

Metadatos de ubicación de exportación — Datos que identifican o describen la ubicación de un share en el backend de almacenamiento.

Fuentes

OpenStack Security Advisory OSSA-2026-046 | https://security.openstack.org/ossa/OSSA-2026-046.html

Red Hat Bugzilla — CVE-2026-71195 | https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2026-71195