Vulnerabilidad en Cloudflare Containers: exposición de datos entre tenants

Si tu empresa ejecuta cargas de trabajo en Cloudflare Containers o Sandboxes, esto te interesa: un investigador de seguridad descubrió que era posible recuperar bloques de disco residuales de otros clientes alojados en el mismo servidor físico. Cloudflare ya ha corregido el problema en toda su flota y asegura que no hay evidencia de que se hayan comprometido datos reales. No necesitas hacer nada en tu lado, pero conviene entender qué ha pasado y por qué este tipo de fallos importa cuando compartes infraestructura.

Qué ha pasado

El 4 de septiembre de 2026, el investigador Oren Yomtov, del equipo de seguridad de Accomplish, reportó de forma responsable una vulnerabilidad a través del programa de bug bounty (recompensas por encontrar vulnerabilidades) de Cloudflare. El fallo afecta a Cloudflare Containers y, por extensión, a Cloudflare Sandboxes, que está construido sobre la misma base.

El problema radica en cómo Containers gestiona el almacenamiento de disco. Cada contenedor se ejecuta dentro de una máquina virtual dedicada basada en Firecracker (el monitor de máquinas virtuales que utiliza Cloudflare para aislar cargas de trabajo). Firecracker presenta el disco al contenedor como /dev/vdc, y ese disco raíz escribible se gestiona mediante Linux device mapper thin provisioning (dm-thin), un sistema de aprovisionamiento ligero.

¿Qué hace exactamente el thin provisioning? En lugar de reservar todo el espacio de disco por adelantado, asigna bloques físicos solo cuando el contenedor escribe datos. Esto permite que un mismo servidor aloje muchos más contenedores de los que cabría si cada uno reservara su cuota completa desde el inicio. Es una técnica habitual en entornos cloud porque optimiza costes y recursos, pero introduce un riesgo: si los bloques liberados por un contenedor anterior no se borran antes de reasignarse a otro, el nuevo contenedor puede leer restos de lo que había antes.

Eso es exactamente lo que ocurrió aquí. Un cliente con una cuenta Workers Paid podía leer esos bloques residuales y encontrar fragmentos de datos que habían pertenecido a otro contenedor en el mismo host. Es lo que en seguridad se conoce como exposición de datos entre tenants: no es que alguien entre en tu sistema, sino que la propia plataforma reutiliza recursos sin limpiarlos del todo.

En su comunicado, Cloudflare no menciona ningún identificador CVE ni puntuación CVSS para este fallo.

• 4 de septiembre de 2026 — Oren Yomtov (Accomplish) reporta la vulnerabilidad vía el programa de recompensas de Cloudflare.
• Entre el 4 y el 24 de septiembre de 2026 — Cloudflare investiga, valida el fallo y despliega la corrección en toda la flota.
• 24 de septiembre de 2026 — Cloudflare publica el análisis detallado en su blog.

¿Afecta a mi empresa?

El fallo afecta a la infraestructura de Cloudflare Containers y de Cloudflare Sandboxes. Si tu empresa utiliza cualquiera de estos dos servicios, tus cargas de trabajo se ejecutaban en un entorno multi-tenant (varios clientes compartiendo la misma infraestructura física) donde los contenedores se asignan automáticamente a servidores elegibles; el cliente no elige ni controla el host físico.

Hay varios matices importantes:

• La técnica no permitía apuntar a un cliente, carga de trabajo, host o dato concreto. Era una lectura oportunista de bloques residuales: el atacante no podía elegir de quién leía ni qué encontraba.
• No se garantizaba que hubiera datos útiles en esos bloques. Dependía de lo que el contenedor anterior hubiera escrito y de si esos bloques concretos se habían reasignado al nuevo contenedor.
• Cloudflare revisó su telemetría histórica de E/S de disco y no encontró evidencia de explotación maliciosa. La única actividad atribuible a esta técnica provenía de los propios investigadores y de ingenieros de Cloudflare realizando validación autorizada.

Si no usas Cloudflare Containers ni Sandboxes, este fallo no te afecta directamente. Pero si operas en cualquier plataforma multi-tenant con almacenamiento compartido, el caso es un recordatorio útil: el thin provisioning es una práctica estándar en la nube, y el riesgo de bloques residuales existe en cualquier proveedor que no implemente un borrado activo al liberar recursos. Seguramente te suena la idea de que “en la nube todo está aislado”; este incidente demuestra que el aislamiento depende de los detalles de implementación.

Qué hacer, paso a paso

1. Verificar si usas los servicios afectados

Revisa en tu panel de Cloudflare si tienes cargas de trabajo desplegadas en Containers o Sandboxes. Si no los utilizas, no necesitas hacer nada más respecto a este fallo concreto.

2. Saber que el parche ya está aplicado

Cloudflare desplegó la corrección en toda la flota de Containers sin necesidad de que los clientes cambien nada en su configuración. No hay versión que actualizar ni parámetro que modificar de tu lado. La corrección se aplicó entre el 4 y el 24 de septiembre de 2026, aunque Cloudflare no ha publicado la fecha exacta del despliegue.

3. Evaluar la sensibilidad de los datos que procesas

Aunque Cloudflare afirma que no hay evidencia de compromiso, si tus contenedores manejan datos especialmente sensibles (credenciales, datos personales, información financiera), valora si necesitas una revisión interna o comunicar el incidente a tu DPO por precaución, sobre todo de cara al RGPD. El artículo 33 del RGPD obliga a notificar brechas a la autoridad de control en 72 horas cuando hay riesgo para los derechos de las personas. En este caso, Cloudflare dice que no hubo compromiso real, pero la decisión de documentarlo o no es tuya como responsable del tratamiento.

4. Revisar tu modelo de amenazas en entornos multi-tenant

Este tipo de vulnerabilidad —bloques de disco no borrados que se reasignan entre tenants— no es exclusivo de Cloudflare. Es un riesgo conocido en cualquier infraestructura compartida que use thin provisioning. Si trabajas con otros proveedores cloud, pregunta cómo gestionan el borrado de bloques al liberar recursos. Algunas preguntas concretas que puedes hacer a tu proveedor:

• ¿Se aplica un borrado (zeroing) de los bloques de disco antes de reasignarlos a otro cliente?
• ¿Qué mecanismo de aislamiento existe entre máquinas virtuales de distintos tenants?
• ¿Tienen un programa de bug bounty activo y publican los incidentes de seguridad que les reportan?

La transparencia de Cloudflare en este caso —publicar un análisis detallado y colaborar con el investigador— es un buen indicador. No todos los proveedores lo hacen.

5. Documentar el incidente en tu registro de seguridad

Aunque no requiera acción técnica, registra el evento en tu sistema de gestión de incidentes. Si mañana un auditor pregunta, tendrás la trazabilidad de que lo evaluaste y de que el proveedor lo resolvió. Incluye la fecha de publicación (24 de septiembre de 2026), la confirmación de que la corrección no requiere intervención del cliente y la conclusión de Cloudflare sobre la ausencia de explotación maliciosa.

En resumen

• Cloudflare ya ha corregido el fallo en toda la flota de Containers. No necesitas cambiar nada en tu configuración.
• La vulnerabilidad permitía leer bloques de disco residuales de otros tenants, pero no se podía dirigir a un cliente o dato concreto.
• Cloudflare no ha encontrado evidencia de explotación maliciosa en su telemetría histórica.
• Si procesas datos sensibles en Containers o Sandboxes, valora informar a tu DPO como medida de diligencia.
• Aprovecha para revisar con cualquier proveedor cloud cómo gestiona el borrado de almacenamiento en entornos compartidos: este riesgo no es exclusivo de Cloudflare.