Cloudflare parchó una vulnerabilidad cross-tenant en Containers

Una falla en el almacenamiento de Cloudflare Containers exponía bloques de disco de otros clientes

El 4 de septiembre de 2026, el investigador de seguridad Oren Yomtov, del equipo de Accomplish, reportó de forma responsable una vulnerabilidad en Cloudflare Containers y en Cloudflare Sandboxes —este último construido sobre el primero— a través del programa de bug bounty de Cloudflare. Según el reporte oficial de la compañía, la falla ya fue remediada por completo y, tras revisar la telemetría histórica de I/O de disco, no hay evidencia de que datos de clientes hayan sido comprometidos.

El artículo, publicado por el propio blog de Cloudflare el 24 de septiembre, describe el problema como un caso clásico de exposición de datos entre tenants: cualquier cliente con una cuenta Workers Paid podía, en teoría, leer bloques de disco que habían pertenecido a Containers de otros clientes ejecutados en el mismo host físico.

¿Cómo funcionaba técnicamente el exploit?

Para entender el alcance, hay que mirar debajo del capó del almacenamiento.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Cloudflare Containers corre cada workload dentro de una micro-MV powered por Firecracker (el hipervisor de código abierto que Cloudflare desarrolló hace años). Cada contenedor recibe un disco raíz presentado como /dev/vdc, que se construye con dm-thin, el mecanismo de thin provisioning del device mapper de Linux. dm-thin asigna almacenamiento físico solo cuando el disco virtual escribe en una región previamente no mapeada.

El pool afectado utilizaba bloques de 64 KiB y una configuración con la opción skip_block_zeroing. En términos simples: cuando un bloque se reasignaba a un nuevo contenedor, dm-thin no lo limpiaba antes de entregarlo. Si el nuevo contenedor escribía solo 4 KiB en una región de 64 KiB, los 60 KiB restantes podían conservar datos del tenant anterior.

El proof of concept reportado por Accomplish siguió estos pasos:

Crear un contenedor con una cuenta Workers Paid.
Abrir el disco raíz en /dev/vdc.
Leer el disco y guardar una línea base.
Escribir un bloque de 4 KiB en cada región alineada a 64 KiB correspondiente al espacio libre del sistema de archivos ext4.
Releer los bloques resultantes.
Analizar solo los bytes no sobrescritos por el contenedor nuevo.

La técnica no permitía seleccionar a un cliente víctima ni acceder a un disco activamente montado: dependía de que dm-thin reasignara bloques previamente liberados en el mismo host. Aún así, durante las pruebas los investigadores recuperaron estructuras de directorios, páginas de bases de datos e incluso bases SQLite completas en 18 de 24 colocaciones.

Por qué importa: implicancias del aislamiento multi-tenant

El caso es un recordatorio de lo que está en juego cuando una plataforma SaaS ofrece infraestructura multi-tenant. Cualquier debilidad en las capas bajas de almacenamiento —un hipervisor, un pool de bloques, un sistema de archivos— se traduce en un cruce del límite de aislamiento entre clientes.

Aunque Cloudflare subraya que la técnica no permitía apuntar a un cliente específico, el potencial incluía desde metadatos del sistema de archivos hasta datos de aplicación sin que el atacante supiera de quién eran originalmente. En entornos donde los Containers procesan credenciales, tokens o snapshots de bases de datos, eso es exactamente el tipo de borde difuso que más cuesta defender.

El incidente se inscribe en una tendencia más amplia que el equipo de investigación de Sysdig documentó en julio de 2026 con CVE-2026-55255, una vulnerabilidad de tipo IDOR en Langflow que un operador combinó con CVE-2026-33017 para cosechar credenciales embebidas en flujos de otros tenants, según reportó Help Net Security. La lección fue la misma: el riesgo crítico no siempre está en la aplicación, sino en los puntos donde la lógica del proveedor "bendice" un camino de ejecución que cruza límites.

Qué hizo Cloudflare para mitigar el problema

La respuesta fue escalonada, no un parche único:

Paso 1: eliminar la opción skip_block_zeroing de la configuración del pool dm-thin en toda la flota. Esto restauró el comportamiento por defecto de dm-thin de limpiar los bloques nuevos antes de exponerlos, neutralizando la técnica reportada. Los investigadores confirmaron de forma independiente que su PoC dejó de funcionar tras este cambio.
Paso 2: el zeroing no afecta a mapeos ya existentes en discos en ejecución ni al caché de snapshots de imágenes OCI en cada host. Por eso Cloudflare retiró todos los discos en ejecución y eliminó los snapshots de imagen en caché creados antes de la mitigación, dreneando hosts en horarios de bajo tráfico, reiniciando las micro-MV y limpiando las cachés.
Paso 3: revisaron la telemetría de I/O de disco retenida con firmas de detección basadas en la relación característica entre escrituras pequeñas y lecturas grandes del PoC, y solo identificaron actividad atribuible a los propios investigadores e ingenieros de Cloudflare durante la validación autorizada.

El plazo completo, del reporte al cierre: 15 días desde la divulgación (4 de septiembre) hasta la limpieza total de snapshots pre-mitigación (19 de septiembre).

Qué significa esto para tu startup

Si tu producto corre —o piensas correr— sobre Workers Containers, Sandboxes o cualquier servicio serverless multi-tenant, la noticia tiene tres lecturas concretas:

No requiere acción de tu lado. El blog oficial es claro: la remediación no exige cambios de configuración por parte de los clientes. Tus deployments existentes están seguros bajo el nuevo régimen de zeroing.
El modelo de amenaza cambió, no desapareció. Antes de la mitigación, cualquier cuenta de pago era un atacante potencial. Ahora ese vector específico está cerrado, pero el patrón —pequeñas escrituras en regiones grandes como canal lateral— debería formar parte de tu checklist interno al evaluar proveedores de aislamiento.
Evalúa el disclosure como señal de madurez. El timeline de Cloudflare (reporte a las 15:26 UTC, incidente abierto a las 18:45, fix mergeado a las 21:27, despliegue iniciado a las 23:15) es el tipo de respuesta rápida y transparente que vale la pena exigir contractualmente a cualquier proveedor de infraestructura crítica. Si tu stack incluye un SaaS multi-tenant, pregunta a tu proveedor cuánto tarda de media en ir de disclosure público a parche total.

Acciones concretas para esta semana

Audita los logs de tus Containers entre el 4 y el 19 de septiembre en busca de patrones de I/O anómalos (escrituras de 4 KiB en regiones grandes seguidas de lecturas grandes) y compara contra la telemetría que el propio Cloudflare ofreció como referencia en su análisis.
Revisa tu política de tratamiento de datos sensibles en payloads que persistan en disco dentro de Containers: aplica cifrado en reposo del lado de la aplicación aunque el proveedor asegure zeroing, porque ningún control de infraestructura es 100% a prueba de futuras variantes.
Documenta los SLAs de seguridad de tus proveedores para tener claros los tiempos de remediación y los compromisos de transparencia ante incidentes. Esto será clave si un día necesitas justificar ante un cliente enterprise que tu plataforma sigue siendo segura.