Una vulnerabilidad en los servicios de contenedores de Cloudflare ha puesto en evidencia los riesgos latentes del almacenamiento compartido en infraestructuras multiinquilino. El fallo, corregido en septiembre de 2026, permitía a un atacante con una cuenta Workers de pago recuperar datos residuales de otros clientes alojados en el mismo servidor físico. Aunque Cloudflare asegura que no hubo exposición real de información de clientes, el incidente revela cómo detalles sutiles en la gestión de bloques de almacenamiento pueden quebrantar las barreras de aislamiento entre inquilinos.
Qué son los Cloudflare Containers y por qué importa esta vulnerabilidad
Cloudflare Containers es un servicio disponible dentro del plan Workers Paid que permite a los desarrolladores ejecutar aplicaciones containerizadas directamente en la infraestructura de Cloudflare, junto a los Cloudflare Workers. Es una plataforma utilizada por empresas y desarrolladores para ejecutar servicios backend, procesar trabajos por lotes y entornos de ejecución de código. Al tratarse de un entorno compartido, el aislamiento entre distintos clientes —la separación de datos y recursos— es un pilar fundamental de seguridad. La vulnerabilidad descubierta por el investigador Oren Yomtov, de la empresa Accomplish, demostró que ese aislamiento podía romperse mediante un fallo en la gestión del almacenamiento subyacente.
El fallo técnico: un pool de almacenamiento compartido sin limpieza de bloques
El origen del problema residía en un pool de almacenamiento compartido configurado para omitir la puesta a cero de los bloques reutilizados de 64 KiB. En términos prácticos, cuando se eliminaba el volumen thin que respaldaba el disco raíz de un contenedor, sus bloques físicos volvían a un pool que servía a cargas de trabajo de distintas cuentas de clientes. Al asignar esos bloques a un nuevo contenedor, el sistema no sobrescribía todo el bloque con ceros, sino que solo escribía los datos necesarios en la región solicitada.
El exploit funcionaba de la siguiente manera: los investigadores escribían únicamente 4 KiB en una región no utilizada del disco de un nuevo contenedor. Esta operación forzaba la asignación de un bloque físico reutilizado de 64 KiB. Como el bloque no había sido puesto a cero, solo los primeros 4 KiB eran sobrescritos por la nueva escritura; los 60 KiB restantes seguían conteniendo los datos del cliente anterior. De esta forma, un atacante podía leer fragmentos de información residual de otros clientes sin necesidad de romper ninguna autenticación adicional.
¿Cómo funcionaba la vulnerabilidad de Cloudflare Containers?
La vulnerabilidad aprovechaba un pool de almacenamiento compartido que no limpiaba los bloques de 64 KiB al reasignarlos entre distintos contenedores. Al escribir solo 4 KiB en un bloque reutilizado, los 60 KiB restantes permanecían intactos, permitiendo la lectura de datos residuales de otros clientes. El fallo fue reportado por el investigador Oren Yomtov a través de HackerOne el 4 de septiembre de 2026 y fue corregido por Cloudflare el 19 de septiembre de ese mismo año.
El descubrimiento: metodología y resultados de la investigación
Oren Yomtov, investigador de seguridad en Accomplish, reportó el fallo a través de HackerOne el 4 de septiembre. Para demostrar la vulnerabilidad, el equipo realizó pruebas sobre la infraestructura de Cloudflare. Encontraron material residual en 18 de las 24 ubicaciones de contenedores probadas y en 20 de los 22 nodos subyacentes analizados. Los datos recuperables incluían estructuras de directorios, páginas de bases de datos y bases de datos SQLite completas desde el punto de vista estructural.
Según la divulgación de Cloudflare, un atacante podría haber accedido a archivos de otros clientes, como listados de directorios, bases de datos SQLite, perfiles de Chromium, archivos .env y archivos de credenciales. La explotación exitosa habría cruzado la frontera de aislamiento entre inquilinos y podría haber expuesto metadatos del sistema de archivos, estructuras de directorios, páginas de bases de datos y datos de aplicaciones. Sin embargo, el atacante no tendría control sobre la víctima o el servidor, ni podría leer un disco que estuviera activamente montado y en uso.
Evaluación del riesgo y exposición real
Cloudflare aclaró que los investigadores utilizaron scripts que solo realizaban comprobaciones y devolvían recuentos agregados, no el contenido real de los discos. Por lo tanto, no se expusieron datos reales de clientes durante esta evaluación. Tampoco se demostró ninguna capacidad para modificar datos de otros clientes o interferir con sus cargas de trabajo en el servicio de Cloudflare.
Tras examinar registros, telemetría y datos históricos, la compañía no encontró evidencia de que los datos de los clientes hubieran sido expuestos mediante el método descrito por Accomplish. No obstante, la mera existencia de la vulnerabilidad subraya la importancia de los procesos de zeroing en entornos multiinquilino, especialmente cuando se utiliza almacenamiento thin provisioned.
Tipos de datos residuales encontrados durante las pruebas
| Tipo de dato | Descripción | Frecuencia en las pruebas |
|---|---|---|
| Estructuras de directorios | Listados de archivos y carpetas de otros contenedores | Común (18 de 24 contenedores) |
| Páginas de bases de datos | Fragmentos de bases de datos SQLite y otros motores | Común (18 de 24 contenedores) |
| Bases de datos SQLite completas estructuralmente | Archivos de bases de datos con esquemas y datos parciales | Observado en múltiples nodos |
| Archivos .env y de credenciales | Variables de entorno y claves de acceso | Potencialmente expuestos |
| Perfiles de Chromium | Datos de navegación y sesiones almacenadas | Potencialmente expuestos |
La respuesta de Cloudflare: parche automático y medidas correctivas
Cloudflare actuó con rapidez tras recibir el reporte. El 19 de septiembre de 2026, la compañía completó todas las acciones de mitigación. En concreto, eliminó la configuración que provocaba la omisión del zeroing de bloques, retiró los discos de contenedores existentes y limpió las instantáneas en caché que pudieran contener asignaciones antiguas. Todas estas correcciones se aplicaron automáticamente a la infraestructura, sin que los clientes necesitaran realizar ninguna acción para protegerse.
La empresa también afirmó que no encontró evidencia de que los datos de los clientes hubieran sido comprometidos. Aun así, la vulnerabilidad representa un recordatorio de que incluso los proveedores de infraestructura más sofisticados pueden tener puntos ciegos en la gestión del almacenamiento compartido.
Implicaciones para la seguridad en la nube y lecciones aprendidas
El caso de Cloudflare Containers ilustra un desafío fundamental en la virtualización y los contenedores: el aislamiento a nivel de almacenamiento. Mientras que la mayoría de los proveedores se centran en asegurar el hipervisor o el runtime de contenedores, la capa de almacenamiento puede convertirse en un vector de ataque si no se gestiona con el mismo rigor. La omisión del zeroing en bloques reutilizados es un error clásico de configuración que puede tener consecuencias graves en entornos multiinquilino.
Para las empresas que utilizan Cloudflare Workers, esta vulnerabilidad no representó un riesgo material dado que fue corregida antes de que pudiera ser explotada de forma maliciosa. Sin embargo, el incidente refuerza la necesidad de revisar las políticas de seguridad de los proveedores de nube, especialmente en lo relativo a la limpieza de datos entre inquilinos. La transparencia con la que Cloudflare divulgó el fallo —publicando un informe técnico detallado y confirmando la rapidez de la corrección— es un ejemplo positivo de cómo gestionar este tipo de incidentes.
Desde una perspectiva más amplia, la vulnerabilidad subraya que el modelo de responsabilidad compartida en la nube no solo aplica a la configuración de los clientes, sino también a las decisiones internas de los proveedores sobre cómo gestionan recursos como el almacenamiento. Los desarrolladores que construyen aplicaciones sobre Workers Paid deben confiar en que el proveedor mantiene un aislamiento robusto; este incidente demuestra que esa confianza debe ser verificada periódicamente, tanto por parte del proveedor como mediante investigaciones externas como la de Accomplish.
El futuro de la seguridad en plataformas serverless y de contenedores pasará inevitablemente por auditorías más profundas del comportamiento del almacenamiento subyacente. Herramientas como las pruebas de fuzzing en la capa de bloques o la verificación sistemática del zeroing post-eliminación podrían convertirse en estándares de la industria. Mientras tanto, la comunidad de seguridad y los equipos de infraestructura pueden extraer una lección clara de este caso: nunca asumir que un bloque reutilizado está limpio a menos que se haya verificado explícitamente que se ha puesto a cero.
