Cloudflare corrigió una vulnerabilidad entre inquilinos en sus servicios Cloudflare Containers y Cloudflare Sandboxes, después de que investigadores del equipo de Accomplish demostraran que un usuario con una cuenta Workers Paid podía recuperar partes residuales de bloques de almacenamiento utilizados anteriormente por contenedores de otros clientes en el mismo host. El investigador Oren Yomtov informó del problema a la empresa el 4 de septiembre de 2026 a través de su programa de recompensas por vulnerabilidades, y Cloudflare afirma que no encontró pruebas de que los datos de los clientes hubieran quedado expuestos.
¿Cómo surgió el problema?
Containers utiliza la tecnología de aprovisionamiento ligero Linux device mapper para proporcionar un disco raíz escribible dentro de una máquina virtual que funciona mediante Firecracker. Los grupos de almacenamiento afectados utilizaban bloques de 64 kilobytes con la opción skip_block_zeroing activada, lo que significaba que los bloques reasignados no se ponían a cero antes de estar disponibles para un nuevo contenedor.
Al escribir solo 4 kilobytes en una parte de un bloque nuevo, la parte restante de 60 kilobytes podía conservar datos del propietario anterior. Una lectura posterior desde el dispositivo sin procesar /dev/vdc podía revelar esos bytes, aunque el nuevo contenedor nunca los hubiera escrito.
¿Qué demostró la prueba?
La explotación no permitía seleccionar un cliente, contenedor o host concreto, y tampoco estaba garantizada la aparición de residuos de datos. No obstante, los investigadores informaron de que observaron material residual en 18 de las 24 ubicaciones probadas y en 20 de los 22 nodos principales distribuidos en cuatro continentes. Entre los tipos observados había estructuras de directorios, páginas de bases de datos y bases de datos SQLite estructuralmente completas.
Los investigadores utilizaron pruebas de hash y metadatos del sistema de archivos ext4 para distinguir los bloques de su sistema de prueba de los bloques procedentes de otros sistemas de archivos. Según los resultados publicados, identificaron 2.700 nodos de directorio ajenos, mientras que ninguno de los 5.614 bloques de directorio de prueba se atribuyó a los sistemas de los investigadores. Cloudflare afirma que los materiales que se le entregaron no incluían nombres de archivos, identificadores, credenciales ni contenido recuperado, y que los investigadores eliminaron de forma segura los datos que tenían en su poder.
¿Cómo corrigió Cloudflare el fallo?
La empresa eliminó la opción skip_block_zeroing de la configuración de los grupos dm-thin, de modo que los bloques nuevos volvieron al comportamiento predeterminado de ponerlos a cero antes de hacerlos disponibles. Los investigadores confirmaron de forma independiente que la prueba de concepto dejó de funcionar después de este cambio.
Sin embargo, poner a cero las nuevas asignaciones no era suficiente, porque algunos bloques aún estaban asociados a discos de contenedores existentes o a instantáneas temporales de capas de imágenes OCI. Por ello, Cloudflare detuvo los discos de contenedores antiguos, eliminó las instantáneas almacenadas en caché antes de la corrección, vació los hosts, reinició las máquinas virtuales y limpió la caché de imágenes. Esta limpieza concluyó el 19 de septiembre de 2026, mientras que el despliegue de la corrección principal finalizó el 7 de septiembre.
¿Por qué importa esta noticia?
La importancia del incidente radica en que demuestra que el aislamiento entre inquilinos en la infraestructura de nube no depende únicamente de las máquinas virtuales; los detalles de la reutilización del almacenamiento y del comportamiento del aprovisionamiento ligero pueden abrir un canal para la filtración de datos inactivos. Al mismo tiempo, las limitaciones prácticas eran claras: la prueba no podía dirigirse a una víctima concreta ni acceder a un disco conectado físicamente, y no demostró la modificación de datos de otro cliente ni un impacto en la disponibilidad de sus cargas de trabajo.
Cloudflare revisó los registros históricos de medición de entrada y salida de los discos en busca de un patrón distintivo que combinara escrituras de 4 kilobytes con lecturas de mayor tamaño. Atribuyó la actividad compatible con ese patrón a los investigadores y a sus propios ingenieros durante la verificación autorizada, y no encontró actividad adicional que indicara la explotación del ataque por parte de terceros. Según la empresa, los clientes de Cloudflare no deben realizar ninguna acción.