Cloudflare Containers: qué enseña una fuga de bloques sin zeroing

Una máquina virtual dedicada es una barrera importante, pero no es la garantía completa de aislamiento de una plataforma multiinquilino. Cloudflare publicó el 24 de septiembre de 2026 el análisis de una exposición potencial en Cloudflare Containers y Cloudflare Sandboxes, que se construye sobre Containers. El problema estaba en una capa más baja: la reutilización de bloques físicos de almacenamiento sin limpiarlos antes de entregarlos a otro workload.

La corrección ya está aplicada en la flota de Cloudflare. Para quienes operan backend o plataformas, el interés del caso está en la pregunta que deja abierta: ¿qué ocurre con los bytes de un tenant cuando un volumen se destruye, un snapshot se recicla o una caché de imagen vuelve a usarse? La respuesta no puede descansar solo en que cada contenedor se ejecute dentro de una VM.

Qué confirmó Cloudflare

El investigador Oren Yomtov, de Accomplish, reportó el problema el 4 de septiembre mediante el programa de recompensas de Cloudflare. El proveedor explicó que Containers coloca workloads automáticamente en servidores elegibles y que el cliente no puede escoger el host subyacente. En esa infraestructura, un cliente con una cuenta Workers Paid podía llegar a recuperar bloques residuales que antes habían pertenecido a otros Containers del mismo host.

Hay dos límites importantes en esa descripción. La técnica no permitía seleccionar una víctima, un workload, un host o un dato concreto; además, la presencia de material residual no estaba garantizada. Tampoco se demostró modificar datos activos ni afectar la disponibilidad de un workload. Cloudflare afirma que no encontró evidencia de explotación maliciosa en la telemetría histórica y que la actividad compatible con la prueba procedía del investigador y de validaciones autorizadas de sus ingenieros. La fuente primaria es el análisis técnico de Cloudflare sobre la vulnerabilidad entre inquilinos.

El resultado de las pruebas reportadas tampoco debe leerse como una tasa universal. En seis ubicaciones de producción, el investigador observó material residual en 18 de 24 placements y en 20 de 22 nodos; identificó estructuras de directorios, páginas de bases de datos y bases SQLite estructuralmente completas. Son observaciones de una prueba controlada en ese despliegue, no una medición aplicable a todos los contenedores ni a todas las plataformas.

La pieza que falló: reutilizar sin zeroing

Cloudflare usaba Linux device-mapper thin provisioning, o dm-thin, para proporcionar el disco raíz escribible de cada Container. La plataforma ejecuta cada instancia dentro de su propia máquina virtual con Firecracker. En el pool afectado, los bloques físicos tenían un tamaño de 64 KiB y se compartían entre workloads de distintas cuentas cuando un volumen se eliminaba.

La documentación del kernel de Linux sobre thin provisioning define skip_block_zeroing como una opción que omite poner a cero los bloques recién aprovisionados. Esa definición no implica que cualquier sistema con thin provisioning sea vulnerable: el riesgo depende de la política de asignación, el patrón de escrituras, la posibilidad de leer almacenamiento crudo, los snapshots y la frontera de aislamiento del servicio.

El modelo conceptual es sencillo:

1. Un bloque físico de 64 KiB deja de estar ligado a un volumen y vuelve al pool compartido.
2. Otro volumen obtiene ese bloque cuando escribe en una región que antes no estaba asignada.
3. Si la escritura nueva ocupa solo 4 KiB y el bloque no se limpió, los 60 KiB restantes pueden conservar bytes antiguos.
4. Una lectura posterior del nuevo volumen puede encontrar bytes que ese tenant nunca escribió.

El detalle decisivo es la escritura parcial. Si se reemplazara el bloque completo, el contenido anterior quedaría cubierto. Con zeroing activo, el bloque recién asignado se limpia antes de exponerse al volumen. Por eso la higiene de bloques es una propiedad de la infraestructura de almacenamiento, no algo que una aplicación pueda corregir desde su código.

Cloudflare describió el comportamiento, pero este artículo no reproduce la prueba de concepto ni ofrece instrucciones para leer dispositivos de terceros. En un entorno autorizado, una prueba defensiva debe usar datos sintéticos, límites explícitos y una validación independiente de que ningún contenido real pueda cruzar la frontera.

Por qué una VM no fue suficiente

La documentación de Cloudflare Containers dice que cada instancia se ejecuta dentro de su propia VM y que esa separación ofrece un aislamiento fuerte respecto de otros workloads. La documentación de seguridad de Sandbox SDK describe, de forma similar, aislamiento de filesystem, procesos, red y cuotas por sandbox.

Esas garantías siguen siendo relevantes. El incidente muestra otra frontera: una VM puede estar aislada a nivel de proceso y red, pero su disco virtual puede depender de un pool compartido. Si la asignación física no sanea los bytes o si un snapshot conserva mappings antiguos, un defecto en esa capa puede convertirse en una exposición que la separación de procesos no evita.

La mitigación de Cloudflare ilustra la diferencia. Quitar skip_block_zeroing protege las nuevas asignaciones, pero no limpia automáticamente bloques que ya estaban mapeados en discos en ejecución ni en snapshots preparados para capas de imágenes OCI. Por eso el proveedor también retiró discos de contenedores, eliminó snapshots antiguos de la caché de imágenes, drenó hosts, reinició las VMs y reconstruyó las capas con asignaciones saneadas. La limpieza de snapshots previos quedó completada el 19 de septiembre.

Qué deberían revisar los equipos de plataforma

El caso no es un parche para Docker ni una señal de que todos los clústeres Kubernetes estén afectados. Es un recordatorio para revisar la cadena completa de almacenamiento que sostiene cualquier servicio multiinquilino.

Preguntas sobre asignación y destrucción

• ¿Los bloques recién asignados se ponen a cero o existe una garantía equivalente documentada por el proveedor?
• ¿Qué ocurre cuando se destruye un volumen: se libera el mapping, se descartan los datos o se sobrescribe el espacio?
• ¿El tamaño de bloque y la granularidad de las escrituras están documentados y cubiertos por pruebas de reutilización?
• ¿La plataforma permite que un workload acceda a un dispositivo crudo, o solo expone una interfaz de filesystem con controles adicionales?

No conviene cambiar opciones de un pool en producción por intuición. skip_block_zeroing es una decisión de infraestructura que puede tener implicaciones de rendimiento; cualquier ajuste debe validarse con el operador, el almacenamiento subyacente y la política de saneamiento.

Snapshots, imágenes y cachés

Un cambio de configuración solo resuelve asignaciones futuras si ya existen mappings que conservan datos anteriores. El inventario debe incluir:

• snapshots de volúmenes y de capas OCI;
• imágenes preextraídas o precalentadas en hosts;
• clones y plantillas que puedan conservar bloques no escritos;
• réplicas, backups temporales y cachés de restauración.

Para cada tipo de artefacto, hay que saber cuándo se crea, cuándo se invalida y qué proceso lo recrea después de una mitigación. La política debe registrar también quién puede forzar una restauración o acceder a un dispositivo fuera del flujo normal.

Pruebas y telemetría

Una prueba de aislamiento no debe limitarse a crear dos contenedores y comprobar que sus rutas visibles son distintas. En un entorno controlado, el equipo puede sembrar patrones sintéticos, destruir y reasignar volúmenes, revisar snapshots y confirmar que los bytes no reaparecen. El resultado debe distinguir entre un cero legítimo, un bloque no aprovisionado y una asignación ya usada.

La telemetría debe conservar al menos el ciclo de vida de volúmenes y snapshots, las asignaciones y liberaciones de bloques, los cambios de pool y relaciones anómalas entre pequeñas escrituras y lecturas posteriores. Cloudflare señala que construyó firmas de detección a partir de esa relación de I/O; la idea defensiva es detectar un patrón inesperado, no buscar contenido de otros tenants.

Qué pedir al proveedor después de un incidente

Un proveedor debería poder responder, con fechas y alcance:

1. Qué configuración originó el riesgo y en qué regiones, pools o generaciones de imágenes estuvo activa.
2. Si se limpiaron solo las nuevas asignaciones o también discos, snapshots y cachés previos.
3. Qué pruebas de reutilización confirmaron que la corrección dejó de exponer bytes residuales.
4. Qué telemetría se revisó, cuánto tiempo se conservó y qué actividad se atribuyó a validación autorizada.
5. Si el cliente debe rotar secretos, recrear workloads o cambiar una configuración propia.

En el caso descrito, Cloudflare indica que no requiere cambios de configuración por parte de sus clientes. Para otros proveedores, el equipo debe separar las acciones que correspondan al servicio de las que sí estén bajo su control, como rotar credenciales si existe evidencia concreta de exposición.

La lección: aislar también significa sanear

El incidente de Cloudflare Containers no convierte a toda la tecnología de contenedores en un riesgo uniforme. Sí demuestra que el aislamiento tiene varias capas: VM, procesos, red, filesystem, asignación física, snapshots, imágenes y telemetría. Una capa sólida no compensa una garantía ausente en otra.

Para un equipo de backend, la comprobación más útil no es preguntar únicamente si cada contenedor tiene su VM. También hay que exigir una respuesta verificable sobre cuándo un bloque queda limpio, cómo se invalidan las copias y qué evidencia existe cuando la plataforma corrige una configuración de almacenamiento. Ese es el control que evita que un dato antiguo viaje silenciosamente con el siguiente workload.

Fuentes directas

• Cloudflare: How Cloudflare addressed a cross-tenant data exposure vulnerability in Containers — cronología, alcance, comportamiento de dm-thin, mitigación, limpieza y revisión de telemetría.
• Linux Kernel Documentation 6.17: Thin provisioning — tamaños de bloque, snapshots y definición de skip_block_zeroing.
• Cloudflare Containers: Lifecycle of a Container — colocación, VM por instancia, runtime y ciclo de vida del disco.
• Cloudflare Sandbox SDK: Security model — aislamiento documentado entre sandboxes y responsabilidades de la aplicación.