Introducción
El 4 de septiembre de 2026, Oren Yomtov, investigador en Accomplish, reportó vía el programa de bug bounty de Cloudflare que un cliente con cuenta Workers Paid podía leer bytes que otro cliente había escrito en el mismo host físico. No hubo escape de VM, no hubo privilegio escalado, no hubo bug en la API de Cloudflare. La fuga ocurrió porque los pools de almacenamiento thin-provisioned estaban configurados con skip_block_zeroing, una opción de rendimiento que evita limpiar bloques antes de reasignarlos. El resultado: hasta 60 KiB de datos de un contenedor anterior quedaban legibles para el siguiente que recibiera ese bloque físico.
Cloudflare parchó el runtime en menos de seis horas desde la recepción del reporte y publicó la divulgación el 5 de octubre. La empresa no encontró evidencia de explotación maliciosa. Pero el caso expone una categoría de riesgo que los equipos de infraestructura subestiman: la garantía de aislamiento que se vende en el plano de virtualización o contenedores no necesariamente se extiende al allocator de bloques que está debajo.
Qué ocurrió
Cada contenedor en Cloudflare Containers corre dentro de una microVM Firecracker con un disco raíz writable provisionado mediante dm-thin (Linux device mapper thin provisioning). Los pools afectados usaban un thin-block size de 64 KiB y tenían activo el flag skip_block_zeroing. Con esa combinación, cuando un contenedor escribía un bloque de 4 KiB en una región no mapeada, dm-thin le asignaba un bloque físico de 64 KiB tomado de un pool compartido entre cuentas. El write del contenedor nuevo reemplazaba solo sus 4 KiB y dejaba intactos los 60 KiB restantes, que podían contener lo que un contenedor anterior hubiera escrito allí.
Los investigadores recuperaron datos en 18 de 24 placements y en 20 de 22 nodos subyacentes distribuidos en cuatro continentes. Usando los checksums de bloques de directorio de ext4, identificaron 5.614 bloques testables —todos provenían de otros tenants— y 2.700 inodes de directorio ajenos. Entre los materiales residuales había estructuras de directorio, páginas de base de datos y bases SQLite estructuralmente completas.
Cloudflare acota el alcance: un atacante no podía elegir víctima, workload ni host; no podía leer un disco activamente montado; y no tenía garantía de que el bloque residual contuviera algo. La exposición dependía de la colocación del workload y de qué bloques liberados dm-thin reasignara. No se demostró modificación de datos ni impacto en disponibilidad.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
La falla no rompe Firecracker ni el hypervisor KVM. Rompe la premisa de que «VM = aislamiento total». Si un equipo corre cargas multi-tenant sobre microVMs compartiendo un pool dm-thin con skip_block_zeroing, tiene la misma vulnerabilidad, independientemente de que use Cloudflare, un cluster GKE con gVisor o un set de Azure Container Apps Sandboxes.
Peter Ward, senior cloud security engineer en Visa, lo resumió en LinkedIn: «That is tenant isolation broken at the storage layer, not an app bug.» Su punto práctico: cualquier plataforma que ofrezca discos efímeros en hosts compartidos necesita checks explícitos de zero-on-allocate o wipe-on-release en el control plane, no solo aislamiento de red. Sherin Shahanas, líder técnico en cloud y ciberseguridad, fue más directo: «Isolated» suele ser una afirmación arquitectónica, no algo que se teste independientemente en el storage layer. La pregunta para cualquier equipo: ¿saben o simplemente asumen que los bloques dealocados se zeroean antes de reasignar?
El timing agrava la relevancia. La divulgación cayó a días del GA de Azure Container Apps Sandboxes (microVMs con aislamiento hardware para workloads de agentes) y de los benchmarks de GKE Pod snapshots (checkpointing de memoria y disco vía gVisor con persistencia en Cloud Storage). Ambos productos venden aislamiento para ejecutar código no confiable. La lección es transversal: la garantía abarca cada capa debajo de la que aparece en el anuncio, incluido el block allocator.
Detalles técnicos
Componente afectado: Linux device mapper thin provisioning (dm-thin), kernel module dm_thin_pool.
Configuración problemática:
thin-pool:
block_size: 64 KiB
skip_block_zeroing: true
Vector de exposición:
Evidencia de recuperación:
- 5.614 bloques de directorio ext4 testados → 100% con inodes ajenos.
- 2.700 inodes de directorio distintos identificados como «foreign».
- Tipos de dato recuperados: estructuras de directorio, páginas de BD, bases SQLite completas (header + data + freelist válidos).
Timeline de respuesta Cloudflare:
Reporte recibido (bug bounty)Sep 4, 15:26Incidente interno abiertoSep 4, 18:45Fix de runtime mergeadoSep 4, 21:27Divulgación públicaOct 5El runtime fix consistió en eliminar skip_block_zeroing de los pools de producción y forzar zeroing en la asignación de bloques thin. Cloudflare también reasignó los bloques residuales en los nodos afectados.
Qué deberían hacer los administradores y equipos técnicos
Si operan dm-thin en producción (Kubernetes, LXC, microVMs propias):
dmsetup table $(dmsetup ls | grep thin-pool) | grep -o ‘skip_block_zeroing’
Si aparece skip_block_zeroing, el pool está expuesto. El flag se define en la creación del pool o en /etc/lvm/profile/ si usan LVM sobre dm-thin.
# Verificar que el kernel soporta zeroing forzado
cat /sys/module/dm_thin_pool/parameters/skip_block_zeroing
# Forzar zeroing en pools existentes (requiere re-create del pool)
lvconvert –poolmetadatasize +10M vg0/pool0
Conclusión
Cloudflare respondió rápido: seis horas entre reporte y fix mergeado, y la divulgación pública llegó un mes después, cuando la remediación ya estaba en producción. No hubo explotación maliciosa. Pero el caso deja una marca concreta para cualquier equipo que diseña aislamiento multi-tenant: la cadena de garantías termina donde termina la capa que verificaste. Firecracker aisló el guest kernel. KVM aisló el hypervisor. dm-thin, con un flag de rendimiento activado, compartió 60 KiB entre strangers.
La pregunta que Peter Ward y Sherin Shahanas repiten en LinkedIn es la que conviene hacer antes de confiar en cualquier plataforma: ¿cada ruta de volumen reutilizado zeroea al asignar, o estás asumiendo? Si no tienen un test automatizado que lo confirme, no tienen una garantía. Tienen una expectativa.