Cloudflare corrige un fallo en Containers que podía exponer datos residuales de otros clientes

Cloudflare ha corregido una vulnerabilidad en su plataforma Containers que podía permitir a un cliente recuperar datos residuales procedentes de cargas de trabajo de otros usuarios que anteriormente habían utilizado el mismo servidor físico. El problema también afectaba a Cloudflare Sandboxes, un servicio construido sobre la infraestructura de Containers.

La compañía asegura que la vulnerabilidad ya está completamente solucionada y que, tras revisar la telemetría histórica disponible, no encontró pruebas de que un actor malicioso la hubiera utilizado para acceder a datos de clientes. Cloudflare tampoco exige que los usuarios realicen cambios adicionales en sus configuraciones.

El problema estaba en la reutilización de bloques de almacenamiento

Cloudflare Containers ejecuta las cargas de trabajo de diferentes clientes sobre una infraestructura compartida, aunque cada contenedor funciona dentro de una máquina virtual independiente. El fallo apareció en el sistema utilizado para gestionar el almacenamiento de los discos virtuales.

La infraestructura utilizaba thin provisioning de Linux mediante dm-thin. Cuando se eliminaba el volumen de un contenedor, sus bloques físicos de almacenamiento podían regresar a un conjunto compartido y ser utilizados posteriormente por otra carga de trabajo.

Una opción denominada skip_block_zeroing hacía que esos bloques no fueran borrados completamente antes de asignarlos de nuevo. En determinadas circunstancias, un nuevo contenedor podía escribir solo una pequeña parte del bloque y leer después bytes que pertenecían a una carga de trabajo anterior.

Podían aparecer estructuras de directorios y páginas de bases de datos

La vulnerabilidad fue comunicada el 4 de septiembre de 2026 por el investigador Oren Yomtov, de Accomplish, mediante el programa de recompensas de Cloudflare. Las pruebas demostraron que era posible recuperar bloques residuales que no pertenecían al contenedor utilizado durante la investigación.

Los investigadores detectaron material residual en 18 de 24 asignaciones probadas y en 20 de 22 nodos subyacentes repartidos por cuatro continentes. Entre las estructuras encontradas había metadatos de directorios, páginas de bases de datos y bases SQLite estructuralmente completas.

Eso no significa que los investigadores accedieran de forma indiscriminada a archivos completos de clientes. Cloudflare señala que la información entregada durante la divulgación responsable no incluía nombres de archivos de terceros, credenciales, direcciones, nombres de host ni otros valores recuperados que identificaran a clientes.

No era posible elegir qué cliente atacar

El alcance del fallo tenía varias limitaciones. Para reproducirlo era necesaria una cuenta de pago de Cloudflare Workers y el atacante no podía seleccionar un cliente concreto, una carga de trabajo específica ni el servidor físico en el que se ejecutaría su contenedor.

Tampoco permitía leer un disco que estuviera conectado activamente a otra carga de trabajo. La exposición dependía de que Cloudflare asignara al nuevo contenedor bloques físicos utilizados previamente y de que en ellos todavía quedaran datos aprovechables.

Por tanto, se trataba de un fallo de aislamiento entre clientes con capacidad potencial para revelar información, pero no de una filtración masiva confirmada de la plataforma.

Cloudflare eliminó la configuración vulnerable y renovó los discos

Como primera medida, Cloudflare eliminó skip_block_zeroing de la configuración de almacenamiento. De este modo, los nuevos bloques vuelven a borrarse antes de quedar disponibles para un contenedor diferente.

La compañía descubrió después que esta medida por sí sola no eliminaba los datos residuales de bloques que ya estaban asignados a discos existentes o almacenados en determinadas cachés. Por ello también retiró discos en ejecución creados antes de la mitigación, reinició máquinas virtuales y eliminó las instantáneas antiguas almacenadas en caché.

El despliegue inicial de la corrección terminó el 7 de septiembre y la limpieza de las instantáneas anteriores a la mitigación quedó completada en toda la infraestructura afectada el 19 de septiembre.

Cloudflare dice que no encontró explotación maliciosa

Cloudflare analizó la telemetría histórica de entrada y salida de disco disponible para buscar patrones compatibles con la técnica utilizada por los investigadores. La compañía identificó actividad correspondiente a las pruebas autorizadas de Accomplish y a las realizadas por sus propios ingenieros, pero asegura que no encontró actividad adicional que indicara una explotación del fallo por terceros.

La compañía considera la vulnerabilidad completamente remediada. Los clientes de Containers y Sandboxes no necesitan instalar un parche ni modificar sus servicios para aplicar la corrección.