Cloudflare ha corregido una vulnerabilidad en su servicio Cloudflare Containers que podía permitir a un cliente recuperar datos residuales de bloques de almacenamiento utilizados anteriormente por contenedores de otros clientes alojados en el mismo servidor. El problema afectaba a la capa de almacenamiento compartida y no al aislamiento del contenedor en sí. La compañía asegura que no ha encontrado evidencias de explotación maliciosa.
Las claves de la vulnerabilidad de Cloudflare Containers en 20 segundos
- Un fallo en
dm-thinpermitía reutilizar bloques de 64 KiB sin borrar completamente su contenido anterior. - Una escritura de 4 KiB podía dejar expuestos hasta 60 KiB de datos residuales.
- Los investigadores recuperaron estructuras de directorios, páginas de bases de datos y bases SQLite completas.
- Cloudflare eliminó la configuración afectada, retiró discos y snapshots antiguos y limpió toda la flota.
- La compañía afirma que sus registros no muestran explotación por terceros fuera de las pruebas autorizadas.
La vulnerabilidad fue comunicada el 4 de septiembre de 2026 por Oren Yomtov, investigador de seguridad de Accomplish, a través del programa de recompensas de Cloudflare en HackerOne. La investigación se centró en Cloudflare Containers y, por extensión, en Cloudflare Sandboxes, que utiliza Containers como base.
El escenario afectaba a una infraestructura multiinquilino en la que los clientes no pueden elegir el servidor físico que aloja sus cargas. Los investigadores demostraron que una cuenta de Workers Paid podía recuperar determinados bloques de almacenamiento que habían pertenecido anteriormente a otros contenedores situados en el mismo host.
Cloudflare subraya que la técnica no permitía elegir a una víctima concreta, un contenedor determinado, un servidor específico ni unos datos concretos. La presencia de información residual tampoco estaba garantizada. El riesgo dependía de cómo se asignaran los recursos de almacenamiento y de qué bloques liberados fueran reutilizados.
El problema estaba en la reutilización de bloques de 64 KiB
Cloudflare Containers utiliza dm-thin, una tecnología de aprovisionamiento ligero de Linux, para proporcionar a cada contenedor un disco raíz escribible. Cada contenedor se ejecuta dentro de una máquina virtual dedicada basada en el monitor de máquinas virtuales Firecracker.
El disco se presenta a esa máquina virtual como /dev/vdc. El sistema de almacenamiento solo asigna espacio físico cuando una unidad virtual escribe sobre una región que todavía no tenía un bloque físico asociado.
En el caso analizado, los pools de almacenamiento utilizaban bloques de 64 KiB. Cuando se eliminaba el volumen thin de un contenedor, sus bloques físicos regresaban a un pool compartido por cargas de trabajo de distintas cuentas.
El problema aparecía porque la configuración afectada incluía la opción skip_block_zeroing. Con ella activada, dm-thin no borraba previamente un bloque físico antes de asignarlo a un nuevo volumen.
La diferencia entre una escritura completa y una parcial era determinante. Si el nuevo propietario escribía los 64 KiB, el contenido anterior quedaba reemplazado. Pero una escritura de solo 4 KiB modificaba únicamente esa parte. Los 60 KiB restantes podían conservar información del propietario anterior.
La vulnerabilidad, por tanto, no consistía en atravesar directamente el aislamiento del contenedor. El acceso se producía mediante la forma en que el almacenamiento físico se reutilizaba entre diferentes cargas de trabajo.
Así funcionaba la prueba de concepto
Los investigadores comprobaron primero que leer una región que todavía no había sido asignada a un bloque físico devolvía ceros. El procedimiento aprovechaba después regiones alineadas con bloques de 64 KiB que correspondían a espacio libre del sistema de archivos ext4.
La prueba escribía un bloque de 4 KiB en cada región seleccionada. Cuando esa escritura provocaba la asignación de un bloque físico reutilizado, los 60 KiB que quedaban fuera de la escritura podían conservar datos anteriores.
Después, una lectura del dispositivo en bruto permitía observar esos bytes que el nuevo contenedor nunca había escrito.
Para determinar si un bloque procedía de su propio sistema de archivos o de otro anterior, los investigadores utilizaron, entre otras técnicas, las sumas de comprobación de los bloques de directorios de ext4. Según el informe publicado por Cloudflare, en seis ubicaciones de producción analizaron 5.614 bloques de directorios y no atribuyeron ninguno al sistema de archivos utilizado en su prueba.
El análisis permitió identificar 2.700 inodos de directorios pertenecientes a otros sistemas de archivos mediante las comprobaciones de integridad utilizadas.
Los investigadores observaron material residual en 18 de 24 ubicaciones y en 20 de 22 nodos subyacentes distribuidos en cuatro continentes. Entre los datos recuperados durante las pruebas había estructuras de directorios, páginas de bases de datos y bases de datos SQLite estructuralmente completas.
Cloudflare señala que los materiales entregados con la investigación no incluían nombres de archivos de terceros, identificadores, credenciales, nombres de host, direcciones ni valores del contenido recuperado. Los investigadores también confirmaron posteriormente que eliminaron de forma segura los datos que habían recuperado.
Cloudflare tuvo que limpiar también discos y snapshots antiguos
La primera medida adoptada por Cloudflare fue retirar skip_block_zeroing de la configuración de los pools dm-thin de toda la flota de Containers. De esta manera, las nuevas asignaciones recuperaban el comportamiento predeterminado de dm-thin, que borra los bloques antes de ponerlos a disposición de un contenedor.
Pero ese cambio por sí solo no solucionaba todos los datos que ya podían estar mapeados en discos existentes. Cloudflare explica que algunos bloques permanecían asociados a discos de contenedores en ejecución y a cachés de snapshots preparados para capas de imágenes OCI.
Por ese motivo, la compañía retiró los discos de contenedores en ejecución y eliminó los snapshots almacenados en caché que se habían creado antes de aplicar la mitigación. También drenó hosts durante periodos de menor actividad, reinició las máquinas virtuales y vació las cachés de imágenes para recrear discos y capas utilizando asignaciones con los bloques correctamente inicializados.
Cloudflare asegura que completó esta limpieza en toda la flota afectada el 19 de septiembre de 2026.
La línea temporal muestra además que la corrección inicial se desplegó rápidamente. La empresa abrió el incidente de seguridad el 4 de septiembre, pocas horas después de recibir el aviso, y comenzó a desplegar los cambios esa misma noche. El despliegue terminó el 7 de septiembre y los investigadores confirmaron el 14 de septiembre que su prueba de concepto había dejado de funcionar.
Sin evidencias de explotación maliciosa
Uno de los puntos que Cloudflare destaca en su investigación es la ausencia de indicios de explotación por parte de terceros.
La compañía utilizó la telemetría histórica disponible sobre operaciones de entrada y salida de los discos para buscar patrones compatibles con la técnica descubierta por los investigadores. La prueba de concepto generaba una relación característica entre determinadas escrituras de 4 KiB y lecturas posteriores de bloques de 64 KiB.
Cloudflare desarrolló firmas de detección a partir de ese comportamiento y las aplicó a los registros disponibles. La empresa identificó actividad atribuible a los investigadores y a sus propios ingenieros durante las pruebas autorizadas, pero afirma que no encontró actividad adicional compatible con el ataque.
Eso limita el alcance conocido del incidente: existe una vulnerabilidad que permitía potencialmente cruzar el límite de aislamiento entre clientes, pero Cloudflare no ha encontrado evidencias de que un atacante externo la utilizara.
El caso también muestra por qué la seguridad de un entorno multiinquilino no depende únicamente del aislamiento lógico entre máquinas virtuales o contenedores. Una capa de almacenamiento que reutiliza recursos físicos debe garantizar que los datos de un propietario anterior no puedan quedar accesibles para el siguiente.
En este caso, la combinación de bloques de 64 KiB, escrituras parciales y la opción skip_block_zeroing creó precisamente ese escenario. Cloudflare ha aplicado la corrección, ha limpiado los recursos históricos afectados y afirma que los clientes no necesitan realizar ninguna modificación en sus configuraciones.
Preguntas frecuentes
¿Qué vulnerabilidad tenía Cloudflare Containers?
Una configuración de dm-thin permitía reutilizar bloques físicos de 64 KiB sin borrarlos completamente. Una escritura parcial de 4 KiB podía dejar hasta 60 KiB con datos residuales del uso anterior.
¿Qué tipo de información podían recuperar los investigadores?
Durante las pruebas encontraron estructuras de directorios, páginas de bases de datos y bases SQLite estructuralmente completas. El acceso dependía de que existieran bloques reutilizados con datos residuales.
¿Cloudflare encontró evidencias de un ataque real?
No. La compañía afirma que su análisis de la telemetría histórica no encontró actividad compatible con la técnica fuera de las pruebas realizadas por los investigadores y sus propios equipos.
¿Los clientes de Cloudflare tienen que hacer algo?
Cloudflare indica que la vulnerabilidad ha sido corregida y que no es necesario realizar cambios de configuración por parte de los clientes.
