Cloudflare ha corregido una vulnerabilidad en su plataforma Containers que podía romper el aislamiento entre clientes al reutilizar bloques de almacenamiento físico. Un investigador consiguió recuperar datos residuales que habían pertenecido a otros contenedores alojados en el mismo entorno, aprovechando una configuración de dm-thin que no borraba completamente los bloques antes de reasignarlos.

Las claves de la vulnerabilidad de Cloudflare Containers en 20 segundos

• El fallo estaba en la capa de almacenamiento y afectaba a bloques físicos de 64 KiB.
• Una escritura de solo 4 KiB podía dejar expuestos los 60 KiB restantes.
• Las pruebas recuperaron estructuras de directorios y datos relacionados con bases de datos.
• El investigador encontró material residual en 18 de 24 ubicaciones analizadas.
• Cloudflare retiró la configuración vulnerable, eliminó snapshots antiguos y no detectó explotación maliciosa.

El incidente fue comunicado a Cloudflare el 4 de septiembre de 2026 por Oren Yomtov, investigador de Accomplish, mediante el programa de recompensas de seguridad de la compañía. Cloudflare afirma que corrigió el problema y que su investigación no ha encontrado indicios de que un tercero aprovechara la vulnerabilidad contra clientes.

El fallo afectaba a Cloudflare Containers y, de forma indirecta, a Cloudflare Sandboxes, construido sobre esta misma tecnología. El escenario era especialmente relevante por tratarse de una infraestructura multiinquilino: distintos clientes podían terminar utilizando bloques físicos pertenecientes al mismo pool de almacenamiento.

La investigación demostró que el aislamiento lógico entre contenedores no impedía por sí solo que aparecieran restos de información de un propietario anterior en determinadas condiciones.

Una escritura de 4 KiB podía dejar 60 KiB expuestos

Cloudflare utiliza dm-thin, el sistema de aprovisionamiento ligero de Linux, para proporcionar discos raíz escribibles a sus contenedores. Cada uno se ejecuta dentro de una máquina virtual basada en Firecracker y recibe el almacenamiento a través del dispositivo /dev/vdc.

El sistema no reserva todo el almacenamiento físico de antemano. Los bloques se asignan cuando una determinada región del disco virtual recibe una escritura.

Los pools afectados utilizaban bloques físicos de 64 KiB. Cuando se eliminaba un disco de contenedor, esos bloques podían regresar al pool compartido y posteriormente asignarse a otra carga de trabajo.

La configuración problemática incluía skip_block_zeroing. Esta opción impedía que dm-thin limpiara el bloque físico antes de entregarlo al nuevo volumen.

El comportamiento tenía una consecuencia concreta. Si el nuevo contenedor escribía los 64 KiB completos, los datos anteriores quedaban sustituidos. Pero si escribía únicamente 4 KiB, los 60 KiB que quedaban fuera de esa escritura podían conservar información anterior.

El investigador construyó una prueba de concepto para localizar regiones de espacio libre del sistema de archivos ext4, escribir 4 KiB en bloques alineados y comprobar después qué información aparecía en las zonas que no habían sido sobrescritas.

La lectura directa del dispositivo permitía entonces observar datos que el nuevo contenedor nunca había generado.

El investigador llegó a identificar bloques de otros sistemas de archivos

La investigación no se limitó a comprobar que existían bytes residuales. Para diferenciar sus propios datos de información procedente de otros sistemas de archivos, el equipo utilizó las sumas de comprobación de bloques de directorios de ext4.

Cloudflare recoge en su análisis que los investigadores estudiaron 5.614 bloques de directorios en seis ubicaciones de producción. Ninguno fue atribuido al sistema de archivos utilizado para la prueba.

El análisis permitió identificar además 2.700 inodos de directorios asociados mediante las comprobaciones de ext4 a otros sistemas de archivos.

Los investigadores observaron material residual en 18 de 24 ubicaciones y en 20 de 22 nodos subyacentes distribuidos por cuatro continentes. Entre los tipos de información recuperada durante la validación había estructuras de directorios, páginas de bases de datos y bases de datos SQLite estructuralmente completas.

El alcance del hallazgo tenía, no obstante, límites claros. La técnica no permitía escoger un cliente concreto como objetivo ni acceder directamente a un disco activo de otra organización. La exposición dependía de que el sistema reasignara determinados bloques que hubieran sido utilizados anteriormente y conservaran información residual.

Tampoco se demostró la posibilidad de modificar los datos activos de otro cliente ni de afectar a la disponibilidad de sus cargas de trabajo.

Cloudflare tuvo que corregir más que la configuración

La primera medida de Cloudflare fue eliminar skip_block_zeroing de los pools dm-thin. Con ello, las nuevas asignaciones recuperaban el comportamiento de limpieza de bloques antes de ponerlos a disposición de un contenedor.

Sin embargo, la compañía detectó que corregir las nuevas asignaciones no era suficiente para eliminar los posibles restos que ya estuvieran presentes en discos y cachés existentes.

Algunos bloques podían permanecer mapeados dentro de discos de contenedores en ejecución. Además, los hosts mantenían en caché snapshots preparados para las capas de imágenes OCI. Un nuevo contenedor podía heredar esos mapeos sin provocar una nueva asignación física del bloque.

Cloudflare decidió por ello retirar los discos de contenedores afectados y eliminar los snapshots almacenados en caché que habían sido creados antes de la corrección.

La operación incluyó el drenaje de hosts, el reinicio de las máquinas virtuales y la limpieza de las cachés de imágenes. Posteriormente se recrearon los recursos utilizando asignaciones con los bloques correctamente inicializados.

La compañía asegura que completó la limpieza de los snapshots anteriores a la mitigación el 19 de septiembre de 2026.

La investigación no encontró explotación maliciosa

Cloudflare también revisó la telemetría histórica de operaciones de disco disponible en su infraestructura para determinar si alguien había utilizado anteriormente una técnica similar.

El equipo desarrolló firmas de detección basadas en el comportamiento observado durante la prueba de concepto. El patrón incluía escrituras de 4 KiB que podían provocar la asignación de bloques reutilizados de 64 KiB, seguidas de lecturas capaces de recuperar datos fuera de la zona sobrescrita.

La revisión identificó actividad generada por los investigadores y por ingenieros de Cloudflare durante las pruebas autorizadas. Según la compañía, no aparecieron indicios de actividad adicional compatible con el método.

Cloudflare afirma por tanto que no ha encontrado evidencias de explotación maliciosa de esta vulnerabilidad.

El caso resulta relevante para la seguridad de las plataformas cloud multiinquilino porque muestra que el aislamiento entre cargas de trabajo depende de varias capas. El contenedor puede estar correctamente separado del resto y, aun así, una configuración incorrecta en el sistema que administra el almacenamiento físico puede generar una vía para recuperar restos de información de otros clientes.

La corrección también muestra por qué un cambio de configuración puede requerir medidas adicionales cuando existen recursos persistentes, cachés o snapshots creados antes de aplicar el parche. En este caso, Cloudflare no se limitó a cambiar dm-thin: también retiró y recreó recursos que podían conservar asignaciones anteriores.

La vulnerabilidad fue corregida sin que los clientes tuvieran que realizar cambios en sus configuraciones, según Cloudflare. La compañía también agradeció al investigador y al equipo de Accomplish la comunicación responsable del problema.

Preguntas frecuentes

¿Qué permitía hacer la vulnerabilidad de Cloudflare Containers?

Podía permitir que un cliente recuperase datos residuales de bloques de almacenamiento que anteriormente habían sido utilizados por otros contenedores en el mismo entorno físico.

¿Por qué una escritura de 4 KiB podía ser suficiente?

Los bloques físicos afectados tenían 64 KiB. Como la configuración no borraba el bloque completo antes de reutilizarlo, una escritura de 4 KiB podía dejar los 60 KiB restantes con información anterior.

¿Qué información encontraron los investigadores?

Durante las pruebas identificaron estructuras de directorios, páginas de bases de datos y bases SQLite estructuralmente completas, además de otros datos residuales de sistemas de archivos.

¿Cloudflare ha confirmado un ataque?

No. Cloudflare asegura que su análisis de la telemetría disponible no encontró actividad compatible con la técnica fuera de las pruebas autorizadas realizadas por investigadores e ingenieros de la compañía.