Cloudflare corrige fallo en Containers que permitía leer datos residuales en discos compartidos

Cloudflare corrigió una vulnerabilidad en su servicio de Containers que permitió a un cliente autorizado leer datos residuales dejados por contenedores de otros clientes en discos compartidos, según comunicaron la empresa y los investigadores que informaron el fallo. El problema no implicó acceso a procesos en ejecución de otros clientes ni la capacidad de elegir a quiénes pertenecía la información recuperada, pero sí dejó bloques de almacenamiento con restos de archivos —directorios, páginas de bases de datos y bases SQLite completas, según el recuento— que un atacante con acceso al contenedor pudo extraer.

Hechos confirmados: el investigador Oren Yomtov, de la firma Accomplish, reportó el fallo a Cloudflare el 4 de septiembre; la causa técnica fue la reconfiguración de discos en modo "thin provisioning" (capacidad granular de asignación en bloques de 64 KB) de modo que, al devolver bloques al pool compartido, el sistema no los limpiaba antes de reasignarlos; Cloudflare reactivó el borrado de bloques nuevos y retiró/reciclaron las unidades en producción, completando la limpieza el 19 de septiembre y divulgando el incidente cinco días después. Los investigadores verificaron el parche el 14 de septiembre y confirmaron que su prueba de concepto dejó de funcionar.

Cómo funcionó técnicamente (explicación): los discos asignados a contenedores se crean mediante un dispositivo de tipo thin provision, que asigna espacio en bloques de 64 KB. Cuando un contenedor se destruye, sus bloques volvieron al pool general. Debido a una configuración que omitía la limpieza (wipe/zero) al reasignar bloques, el siguiente contenedor que recibiera ese bloque podía escribir solo 4 KB dentro de los 64 KB y luego leer el bloque a nivel bruto; el resto de los 60 KB permanecía con los bytes del inquilino anterior. Los investigadores explotaron exactamente eso: escribieron un fragmento pequeño y leyeron el bloque entero desde el nivel de bloque crudo para recuperar datos residuales. Ese vector ataca la reutilización no segura de bloques, no la memoria en caliente ni la integridad de procesos en ejecución.

Qué sistemas y clientes se vieron afectados: Cloudflare Containers y su producto Cloudflare Sandboxes (una capa pensada para ejecutar código no confiable, incluidos agentes de IA) fueron identificados como afectados. Los investigadores también señalaron que la misma configuración de disco afectaba al producto Browser Run, aunque Cloudflare solo nombró Containers y Sandboxes en su comunicado. Cloudflare controla la asignación física de servidores y discos, de modo que la exposición vino del lado del proveedor y no de una elección del cliente.

Alcance observado por los investigadores y por Cloudflare: en pruebas de producción controladas, los investigadores recuperaron material residual en 18 de 24 intentos en servidores elegidos por Cloudflare, y en 20 de 22 máquinas físicas repartidas en cuatro continentes; los restos incluían listados de directorios, perfiles de navegador (Chromium), archivos .env, ficheros de credenciales y bases SQLite, según el informe de los investigadores y la confirmación parcial de Cloudflare. Cloudflare dice que sus indagaciones internas —basadas en firmas creadas a partir de la prueba de concepto— solo hallaron actividad autorizada (la de los investigadores y su propio personal) en los registros conservados.

Lo que está confirmado y lo que sigue incierto: está confirmado que hubo exposición de datos residuales en bloques de disco reasignados y que Cloudflare aplicó dos remediaciones (reactivar el borrado al asignar bloques nuevos y reemplazar/desplegar discos y cachés en producción). Es una estimación razonable —aunque no matemáticamente probada públicamente— que los restos podrían contener secretos útiles (tokens, claves, credenciales) dado que aparecieron .env y bases de datos. Lo incierto es la ventana total de exposición: Cloudflare no especificó desde cuándo estuvo activa la configuración insegura ni por cuánto tiempo en términos absolutos, de modo que no se puede cuantificar con certeza cuántos clientes estuvieron potencialmente expuestos ni durante qué periodo exacto.

Riesgos reales para clientes y consecuencias prácticas: la información recuperada puede incluir credenciales, tokens API, secretos de configuración o porciones de bases de datos que permiten ataques posteriores (reutilización de credenciales, escalada fuera del entorno, acceso a servicios conectados). Aunque no hay evidencia pública de abuso por terceros, la combinación de datos parciales recuperados y mecanismos automatizados de análisis puede facilitar la reconstrucción de secretos. Además, para organizaciones sujetas a requisitos regulatorios o de cumplimiento, la mera posibilidad de exfiltración de datos en un entorno multi-tenant puede requerir notificaciones o revisiones internas.

Medidas concretas que deberían tomar los clientes afectados o en riesgo: en primer lugar, identifique si usa Containers, Sandboxes o Browser Run y qué imágenes o contenedores pudieron contener secretos en disco o en capas de imagen. A continuación, rote inmediatamente cualquier credencial que pudiera haber estado en esos contenedores: tokens de API, claves de bases de datos, secretos en archivos .env y claves SSH. No espere solo a la confirmación del proveedor; la rotación proactiva es una acción de bajo coste frente al riesgo. Revocar tokens y regenerar credenciales en los servicios conectados (bancos de datos, servicios cloud, APIs de terceros) es la medida más directa para mitigar un posible uso indebido.

Otras acciones técnicas recomendadas: deje de almacenar secretos en el sistema de archivos persistente de contenedores; use servicios de secret management (vaults) o mecanismos de gestión de secretos que inyecten valores en tiempo de ejecución sin escribirlos a disco; monte secretos en memoria (tmpfs) cuando sea viable; cifre los datos sensibles a nivel de aplicación antes de escribirlos a disco para que la exposición de bloques no permita leer claves claras. Ver buenas prácticas en gestión de secretos: OWASP Secrets Management Cheat Sheet.

Verificación y monitoreo: revise logs y actividad inusual en los servicios que usan los contenedores afectados; busque accesos desde IPs o patrones inesperados y configure alertas sobre uso anómalo de claves. Aunque Cloudflare informó haber ejecutado detección basada en firmas, conviene aplicar detección propia de anomalías en servicios críticos y auditar imágenes y capas de contenedor en busca de secretos embebidos.

Contexto técnico adicional y referencias: este problema es un ejemplo de cómo las optimizaciones de performance y la configuración a bajo nivel del almacenamiento (thin provisioning y caching de capas) pueden introducir vectores de fuga de datos en entornos multi-tenant. Para entender el mecanismo de thin provisioning y sus riesgos técnicos, puede consultarse la documentación del kernel de Linux sobre Device Mapper Thin Provisioning: kernel.org — Thin provisioning. Para instrucciones prácticas sobre cómo gestionar secretos en contenedores y reducir este tipo de riesgos, la documentación de buenas prácticas de plataformas y orquestadores es útil (por ejemplo, prácticas de Docker y Kubernetes y gestión de secretos).

Conclusión: Cloudflare cerró la vía de ataque detectada y limpió los recursos en producción, y no hay por ahora indicios públicos de abuso masivo. No obstante, la naturaleza del fallo—lectura de datos residuales en discos compartidos—implica que cualquier cliente que haya guardado secretos en imágenes o discos de contenedor debería rotar credenciales y revisar prácticas de gestión de secretos. La lección operativa es clara: en entornos multi-tenant, la defensa debe incluir tanto controles del proveedor como prácticas estrictas de los desarrolladores para no dejar secretos en disco ni confiar exclusivamente en la seguridad física o del hipervisor.

Fuentes y lectura adicional: el comunicado y seguimiento del proveedor están disponibles en el blog de Cloudflare https://blog.cloudflare.com/, y la explicación técnica de thin provisioning en Linux puede consultarse en la documentación oficial del kernel: https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/thin-provisioning.html.