Cloudflare parchea un fallo que dejaba leer datos residuales de otros clientes
El fallo en Containers y Sandboxes permitía a un cliente leer bloques de disco que contenedores anteriores habían dejado sin borrar. Cloudflare ya lo ha corregido y dice que los clientes no deben hacer nada.
Un fallo en Cloudflare Containers permitía a un cliente de pago leer datos que otros contenedores habían dejado en el disco del mismo servidor. Cloudflare y los investigadores que lo encontraron lo han contado esta semana, y la compañía asegura que ya está corregido en todo el servicio sin que el cliente tenga que tocar nada. El ataque no daba control sobre qué datos se obtenían, no afectaba a cargas de trabajo vivas, y tampoco permitía modificar información ajena ni tumbar un contenedor.
Containers ejecuta programas de clientes en servidores compartidos entre muchas cuentas, y es Cloudflare quien decide en qué máquina cae cada uno. Sandboxes, el producto que se vende como entorno seguro para ejecutar código no confiable, incluido el generado por agentes de IA, corre sobre Containers y también estaba afectado.
Bloques de 64 KB y un borrado que no ocurría
El problema estaba en cómo se configuraban los discos compartidos. Cada contenedor recibe un disco construido con thin provisioning, una función de Linux que asigna almacenamiento en bloques de 64 kilobytes. Cuando un contenedor se eliminaba, sus bloques volvían a un pool común a todas las cuentas. Ese pool estaba configurado para saltarse el borrado antes de entregar el bloque al siguiente contenedor, cuando lo normal es que ese borrado venga activado por defecto. Si el contenedor nuevo escribía poco dentro de un bloque reutilizado, el resto seguía conteniendo los datos del anterior.
Para llegar a ellos, los investigadores escribieron un bloque de cuatro kilobytes en espacio sin usar y luego leyeron el bloque entero a nivel de disco bruto. Los 60 kilobytes que no habían escrito seguían ahí. En pruebas sobre producción reportaron material residual en 18 de 24 intentos, cada uno en un servidor elegido por Cloudflare, y en 20 de 22 máquinas subyacentes repartidas por cuatro continentes.
Lo recuperado incluía estructuras de directorios, páginas de base de datos y bases SQLite estructuralmente completas, según Cloudflare. El escrito de los investigadores añade listados de directorios, perfiles de navegador Chromium, archivos .env y ficheros de credenciales, y los describe como archivos de otros clientes. Según su versión, los scripts de análisis solo volcaban recuentos y comprobaciones de formato, no contenido, y lo que enviaron a Cloudflare no llevaba nombres, identificadores ni credenciales de terceros. Esa parte es suya, no de un tercero independiente.
El fallo lo reportó el 4 de septiembre Oren Yomtov, de la firma de seguridad Accomplish, a través del programa de bug bounty.
Dos pasos para cerrarlo
Cloudflare volvió a activar el borrado en los bloques que se entregan nuevos, lo que cortaba el método descrito; los investigadores confirmaron el 14 de septiembre que su prueba de concepto ya no funcionaba. Pero eso no limpiaba los bloques ya mapeados en discos de contenedores en marcha ni la caché de capas de imagen preparadas de cada servidor, que un contenedor nuevo podía heredar y leer. Así que la compañía retiró todos los discos en ejecución y vació esas cachés, drenando y reiniciando servidores en horas de poca carga. Terminó el 19 de septiembre y divulgó el fallo cinco días después.
También buscó indicios de uso ajeno con firmas de detección construidas a partir de la prueba de concepto y de su propia copia del ataque, aplicadas a los registros de actividad de disco que conservaba. Solo aparecieron las pruebas autorizadas de los investigadores y de sus propios ingenieros. Ese hallazgo cubre únicamente los registros que Cloudflare retuvo, y la compañía no dice cuánto abarcan ni desde cuándo estaba puesta esa configuración insegura, así que la ventana de exposición no se puede medir con lo que ha publicado.
Los investigadores sostienen que el mismo montaje afectaba a Browser Run, producto que Cloudflare no menciona en su aviso. Para ellos es su sexto escape de un sandbox de código desde julio, después de los que encontraron en Claude Cowork y Claude Code, la herramienta de línea de comandos de Cursor, Docker y Codex. El patrón se repite: el aislamiento entre inquilinos depende de detalles de configuración que no se ven desde fuera, y nadie puede auditar hacia atrás cuánto tiempo estuvo así.
