Cloudflare borra discos de contenedores reutilizados tras una filtración de datos entre clientes

Cloudflare ha corregido una vulnerabilidad de aislamiento del almacenamiento en Cloudflare Containers que permitía a la carga de trabajo de un cliente recuperar fragmentos de disco que otro cliente había dejado en la misma infraestructura física.

La vulnerabilidad también afectaba a Cloudflare Sandboxes, un servicio basado en Containers que permite ejecutar código no confiable, incluidos programas generados por agentes de IA. El problema exponía datos residuales de aplicaciones, no almacenamiento activo y conectado. Sin embargo, las pruebas demostraron que los bloques recuperables estaban muy extendidos en los sistemas de producción examinados.

Cloudflare aplicó las correcciones automáticamente y completó la limpieza de la infraestructura el 19 de septiembre de 2026. Los clientes no tienen que hacer nada.

Los bloques reutilizados traspasaban los límites entre clientes

Cloudflare Containers ejecuta cargas de trabajo en contenedores para clientes con cuentas Workers de pago. Entre sus usos habituales figuran las aplicaciones de backend, los servicios de procesamiento de tareas y los entornos aislados para ejecutar código.

Cloudflare decide dónde se ejecuta cada contenedor, mientras que las cuentas de varios clientes comparten los servidores y recursos de almacenamiento subyacentes del proveedor. Este diseño exige una separación estricta no solo entre las cargas de trabajo activas, sino también cuando se libera el almacenamiento y se asigna después a otro cliente.

El investigador de seguridad Oren Yomtov, de Accomplish, informó del problema el 4 de septiembre a través del programa de recompensas por errores de Cloudflare, que BleepingComputer identificó como HackerOne.

La vulnerabilidad se manifestaba al eliminar un contenedor. Sus bloques físicos de disco volvían a un grupo compartido que podía asignarse después a contenedores de cuentas no relacionadas. El grupo estaba configurado para no borrar los bloques antes de reutilizarlos, aunque el comportamiento predeterminado solía ser ponerlos a cero.

Por tanto, asignar un bloque a un nuevo cliente no garantizaba que se hubieran borrado todos sus bytes. Las partes que la nueva carga de trabajo no sobrescribía podían conservar información escrita por el usuario anterior.

Una escritura de 4 KiB dejaba al descubierto el resto de un bloque de 64 KiB

El almacenamiento afectado utilizaba thin provisioning de Linux y asignaba espacio en bloques de 64 kilobytes. El thin provisioning asigna capacidad física al almacenamiento lógico a medida que se necesita, lo que evita tener que reservar de antemano todo el espacio de disco previsto.

Los investigadores demostraron una consecuencia directa de la discrepancia entre el tamaño de los bloques asignados y el de las escrituras. Un contenedor recién creado podía escribir 4 KiB en una zona del disco que no estuviera en uso y, después, inspeccionar el bloque físico completo de 64 KiB mediante acceso al disco sin procesar.

La nueva escritura sustituía los primeros 4 KiB. Los 60 KiB restantes podían conservar datos de un contenedor eliminado al que se le hubiera asignado antes el mismo bloque físico.

No se trataba de acceder a archivos de la forma convencional, mediante el sistema de archivos montado de otro cliente. El atacante examinaba el almacenamiento recuperado por debajo de esa capa en busca de estructuras reconocibles entre los bytes que habían quedado atrás.

Cloudflare afirmó que explotar la vulnerabilidad con éxito suponía traspasar los límites de aislamiento entre clientes. Entre los datos que podían quedar expuestos figuraban:

• Metadatos y estructuras de directorios del sistema de archivos
• Páginas de bases de datos y estructuras completas de bases de datos SQLite
• Datos de aplicaciones
• Perfiles del navegador Chromium
• Archivos .env
• Archivos con credenciales

Los hallazgos indican que no era necesario recuperar un archivo normal completo para obtener información útil. Las páginas de bases de datos, los fragmentos de configuración o las entradas de directorio pueden revelar secretos y detalles operativos, aunque solo se recuperen parcialmente.

Las pruebas en producción encontraron restos en la mayoría de los nodos analizados

Los investigadores detectaron material residual en 18 de las 24 ubicaciones de contenedores. También lo encontraron en 20 de las 22 máquinas o nodos subyacentes incluidos en sus pruebas, que abarcaron sistemas de cuatro continentes, según la información publicada sobre la divulgación de Cloudflare y los resultados de los investigadores.

Cloudflare informó de que entre los bloques recuperados había estructuras de directorios, páginas de bases de datos y bases de datos SQLite estructuralmente completas. El informe de los investigadores también identificó perfiles de navegador, archivos de entorno y archivos relacionados con credenciales entre los formatos reconocibles.

Los scripts de análisis generaron recuentos agregados y validaron formatos de datos, pero no recopilaron el contenido de los archivos. Los investigadores afirmaron que su informe a Cloudflare no incluía nombres, identificadores ni credenciales de terceros, ni tampoco contenido recuperado de clientes. El material que recuperaron se mantuvo en privado y se eliminó de forma segura tras presentar el informe.

Cloudflare sostiene que durante la evaluación autorizada no se expusieron datos reales de clientes. Por separado, los investigadores afirmaron que durante las pruebas recuperaron material residual. Ambas declaraciones describen distintos aspectos del ejercicio: las pruebas demostraron que aún se podía acceder a estructuras de datos antiguas, mientras que los investigadores aseguran que evitaron conservar o enviar contenido identificable de terceros.

La vulnerabilidad permitía divulgar datos, no controlar otras cargas de trabajo

El impacto demostrado se limitaba a la confidencialidad. Los investigadores no demostraron que un atacante pudiera modificar archivos activos de otro cliente, interrumpir un servicio ni tomar el control del contenedor de la víctima.

El método tampoco permitía leer un disco mientras siguiera conectado activamente a otra carga de trabajo. Para explotar la vulnerabilidad, era necesario que los bloques físicos se liberaran y volvieran a asignarse a través del grupo de almacenamiento compartido.

Además, un atacante no podía elegir a una víctima concreta. Cloudflare controlaba la ubicación de los contenedores, y los bloques reutilizados disponibles para una carga de trabajo recién iniciada dependían de las decisiones de asignación de la infraestructura. Por tanto, un atacante podía buscar datos residuales, pero no solicitar almacenamiento que hubiera pertenecido a una organización determinada.

Esta limitación reduce la precisión del método, pero no la sensibilidad de los datos que podía revelar. Los secretos guardados en archivos .env, almacenes de credenciales o páginas de bases de datos podían seguir siendo valiosos, independientemente del cliente que los hubiera creado.

Los investigadores también señalaron que Cloudflare Browser Run utilizaba la misma configuración de disco. Cloudflare mencionó Containers y Sandboxes en el alcance divulgado, pero no hizo referencia a Browser Run. Por ello, no está claro si Cloudflare considera que Browser Run también se vio afectado o si su corrección requería medidas adicionales específicas para ese servicio.

Cloudflare no encontró indicios de explotación más allá de las pruebas

Tras reproducir el problema, Cloudflare creó firmas de detección basadas en la prueba de concepto de los investigadores y en sus propias pruebas. Después, buscó comportamientos coincidentes en los registros conservados de actividad de disco.

La empresa solo encontró la actividad autorizada de los investigadores y los ingenieros de Cloudflare. Según informó, el análisis de registros, telemetría e información histórica no aportó indicios de que otra parte hubiera utilizado la misma técnica para exponer datos de clientes.

Sin embargo, la información disponible no especifica hasta qué fecha se remontaban los registros conservados. Cloudflare tampoco indicó cuándo se introdujo la configuración insegura que no ponía los bloques a cero. Por tanto, se desconoce durante cuánto tiempo pudieron recuperarse los bloques residuales.

No se han publicado indicadores de compromiso que los clientes puedan buscar. Como las pruebas pertinentes estaban en los sistemas de almacenamiento y asignación de Cloudflare, es posible que cada cliente tenga poca visibilidad sobre si sus bloques eliminados llegaron a reasignarse.

Corregir la asignación fue solo el primer paso

Al principio, Cloudflare volvió a activar el borrado a cero de los bloques recién asignados. Así se garantizaba que el almacenamiento asignado después de la corrección se borrara antes de que otro cliente pudiera acceder a él.

El 14 de septiembre, los investigadores confirmaron que su prueba de concepto ya no funcionaba. Sin embargo, cambiar la política de asignación no eliminaba las asignaciones históricas que ya existían en la plataforma.

Los bloques podían seguir asociados a discos de contenedores en ejecución. Las capas de imágenes preparadas y las instantáneas en caché también podían conservar asignaciones anteriores. Por ello, Cloudflare retiró todos los discos activos de contenedores y vació las cachés pertinentes; para hacerlo, fue drenando y reiniciando los servidores durante los periodos de menor actividad.

La empresa completó la limpieza el 19 de septiembre de 2026. La corrección se aplicó dentro de la infraestructura de Cloudflare, por lo que los clientes no tienen que parchear sus aplicaciones, rotar las imágenes de contenedor ni cambiar la configuración para recibirla.

No se ha publicado ningún identificador CVE ni una puntuación formal de gravedad. El problema se describe mejor como un fallo de confidencialidad entre clientes que podía dejar expuestos datos residuales potencialmente sensibles, no como una toma de control del host ni como una salida destructiva del contenedor.

Los investigadores afirmaron que este era su sexto caso publicado de escape de un entorno aislado para ejecutar código desde julio. Entre los anteriores figuraban trabajos sobre Claude Cowork y Claude Code, de Anthropic; la herramienta de línea de comandos de Cursor; Docker; y Codex, de OpenAI. En este caso, sin embargo, la capacidad demostrada consistía en recuperar el contenido de discos reutilizados, no en obtener control arbitrario sobre otro cliente o sobre el host de Cloudflare.