Cloudflare corrigió una vulnerabilidad de exposición de datos entre inquilinos en su producto Containers que permitía a un cliente con una cuenta Workers Paid recuperar datos residuales en disco dejados por las cargas de trabajo de otros clientes en el mismo host compartido. El post-mortem de la compañía, publicado en su blog, indica que la falla fue reportada por el investigador de seguridad Oren Yomtov de Accomplish a través del programa de bug bounty de Cloudflare el 4 de septiembre de 2026, y que Cloudflare no encontró evidencia de que la técnica fuera explotada por alguien fuera de la investigación autorizada.

La causa raíz está en la capa de almacenamiento, no en el runtime del contenedor en sí. Cloudflare Containers ejecuta cada carga de trabajo dentro de una máquina virtual dedicada impulsada por el monitor de máquinas virtuales Firecracker, con un disco raíz de escritura respaldado por el thin provisioning de Linux device mapper, o dm-thin, presentado al huésped como /dev/vdc. Los pools de almacenamiento afectados usaban un tamaño de bloque delgado de 64 KiB y estaban configurados con la opción skip_block_zeroing, que le indica a dm-thin que omita la limpieza de bloques recién asignados antes de entregarlos a un contenedor. Cuando se eliminaba un volumen delgado, sus bloques físicos regresaban a un pool compartido entre múltiples cuentas de clientes, y cuando uno de esos bloques se reasignaba más tarde, solo se sobrescribía la parte que un nuevo contenedor realmente escribía. El resto podía seguir conteniendo bytes de un inquilino anterior.

La prueba de concepto, tal como la describe la publicación de Cloudflare, explotó esa brecha directamente: crear un contenedor, abrir el disco raíz en bruto, identificar regiones alineadas de 64 KiB correspondientes a espacio libre en el sistema de archivos ext4 del huésped, y escribir un único bloque de 4 KiB en cada una. Esa pequeña escritura bastaba para activar la asignación por parte de dm-thin del bloque completo de 64 KiB desde el pool compartido; una lectura en bruto posterior de los 60 KiB no sobrescritos podía entonces revelar datos dejados por el inquilino anterior del bloque. Para confirmar que el material recuperado realmente pertenecía a otros clientes y no a su propio sistema de archivos de prueba, los investigadores usaron sumas de verificación de bloques de directorio ext4, una técnica que, según la publicación de Cloudflare, validaron primero probándola contra 162 bloques que habían creado y eliminado deliberadamente ellos mismos, atribuyendo correctamente los 162 a su propio sistema de archivos.

La escala de lo que los investigadores realmente recuperaron es el número que debería preocupar a cualquiera que opere infraestructura de contenedores compartida: en seis emplazamientos de producción, el post-mortem de Cloudflare informa que el equipo examinó 5,614 bloques de directorio comprobables e identificó 2,700 inodos de directorio ajenos distintos mediante análisis de sumas de verificación, ninguno de los cuales pertenecía a su propio sistema de archivos de prueba. Se encontró material residual en 18 de 24 emplazamientos y en 20 de 22 nodos subyacentes distribuidos en cuatro continentes, incluyendo estructuras de directorio, páginas de bases de datos y, según la publicación, "bases de datos SQLite estructuralmente completas". Cloudflare afirma que los materiales que le fueron enviados no contenían valores de contenido recuperado, nombres de archivo, credenciales ni identificadores de terceros, y que los investigadores confirmaron haber eliminado de forma segura los datos recuperados después de la entrega.

La corrección de Cloudflare tuvo dos partes, y la segunda es la que muestra lo difícil que resulta cerrar por completo esta clase de fallo. La mitigación inmediata fue retirar skip_block_zeroing de la configuración del pool dm-thin en toda la flota, restaurando la limpieza por defecto de los bloques recién asignados, un cambio que los investigadores confirmaron de forma independiente que rompía su prueba de concepto. Pero limpiar las nuevas asignaciones no sanitizaba los bloques ya mapeados en discos de contenedores en ejecución ni los almacenados en caché en las instantáneas dm-thin preparadas de cada host para las capas de imágenes OCI, ya que un nuevo contenedor podía heredar esos mapeos en caché sin activar una nueva asignación. Cloudflare dice que tuvo que retirar todos los discos de contenedores en ejecución y limpiar la caché de imágenes de cada host, drenando hosts durante horas de baja actividad y reiniciando máquinas virtuales para forzar la recreación de discos y capas en caché con asignaciones limpiadas, una limpieza que, según afirma, completó en toda la flota antes del 19 de septiembre.

Los límites del exploit importan tanto como su alcance: la publicación de Cloudflare es explícita en que la técnica no podía dirigirse a un cliente, carga de trabajo, host o dato específico, que no había garantía de que hubiera datos residuales presentes, y que los investigadores demostraron que no se modificaron datos activos de otro inquilino ni se afectó la disponibilidad de las cargas de trabajo. Cloudflare dice que su revisión de la telemetría histórica de I/O de disco, utilizando firmas de detección construidas a partir del patrón de lectura/escritura de la técnica reportada, encontró actividad atribuible únicamente a los investigadores y a los ingenieros de Cloudflare que realizaban la validación autorizada.

La cronología es la parte que vale la pena robar para un manual de respuesta a incidentes: reporte a las 15:26 UTC del 4 de septiembre, incidente abierto a las 18:45, corrección del runtime fusionada a las 21:27 el mismo día, despliegue en toda la flota completado el 7 de septiembre, limpieza completa de instantáneas en caché finalizada el 19 de septiembre. Para cualquier equipo que opere infraestructura de contenedores multiinquilino para cargas de trabajo de IA, la lección no es solo "revisa los valores por defecto de limpieza de tu pool de almacenamiento", sino que una limpieza de host compartido después de una corrección en la capa de almacenamiento debe tener en cuenta cada capa de caché que pudiera haber heredado el estado previo a la mitigación, no solo la corrección en vivo en sí.