Cloudflare reveló los resultados de una reevaluación de los ataques Spectre remotos contra la plataforma Cloudflare Workers, realizada durante 2024 y principios de 2025. El equipo de investigación logró construir una prueba de concepto operativa en el entorno de producción y filtrar datos de un Worker víctima a un Worker atacante bajo el control de los investigadores a una tasa de hasta 12 bits por segundo y con una precisión superior al 99 %.
La empresa confirma que el ataque presentado fue corregido en el sistema de producción mediante medidas adoptadas por el equipo de Cloudflare Workers Runtime, y que no encontró indicios de explotación activa durante los tres años anteriores. Los resultados se publicaron en un artículo coescrito por Albert Pedersen, Haocheng Xiao, Sam Ainsworth, Nigel Topham y Martin Schwarzl.
¿Por qué es importante esta investigación?
Workers se basa en ejecutar JavaScript no confiable en el borde, donde decenas de miles de inquilinos pueden compartir un único proceso del sistema operativo mediante aislamientos de V8. Cada Worker tiene un montón de JavaScript separado, lo que mejora el tiempo de inicio y la eficiencia al alojar un gran número de inquilinos, pero también significa que una vulnerabilidad de lectura arbitraria dentro del proceso podría abrir la puerta a la filtración de datos entre inquilinos.
Los ataques Spectre aprovechan la ejecución especulativa de los procesadores. Cuando el procesador predice el resultado de una rama de software y ejecuta instrucciones antes de confirmarlo, los resultados pueden cancelarse posteriormente, pero quedan rastros sutiles en el estado microarquitectónico del procesador, incluida la caché. El atacante puede aprovechar las diferencias en el tiempo de acceso a la memoria para inferir bits de datos que no debería poder leer.
Cloudflare había introducido en 2021 una defensa de producción denominada Dynamic Process Isolation, o DyPrIs, para aislar en procesos separados los scripts que parecen maliciosos. Sin embargo, la reevaluación descubrió una limitación en el mecanismo de ejecución que permitió que el ataque siguiera siendo eficaz durante el tiempo suficiente para superar el aislamiento.
¿Cómo superó el ataque las limitaciones de Workers?
La plataforma restringe los temporizadores locales y no permite memoria compartida ni multihilo, por lo que no están disponibles los métodos de medición tradicionales basados en SharedArrayBuffer. En su lugar, los investigadores utilizaron un temporizador remoto mediante una conexión WebSocket y aprovecharon la amplificación de la señal producida por los eventos de la caché mediante la política de reemplazo tree-based PLRU en la caché L1.
El equipo también diseñó dos tipos de Spectre gadgets. El primero se utilizó para filtrar punteros comprimidos del montón, incluida la dirección base del montón propia del aislamiento. El segundo se basó en una confusión especulativa de tipos para acceder a un puntero sin procesar de 64 bits de ancho, lo que permitió convertir la filtración en una lectura desde una dirección elegida por la parte atacante. En el momento de realizar la investigación, V8 Sandbox todavía no se había implementado en Workers, y TypedArray era uno de los casos que conservaban un puntero sin procesar a su almacenamiento subyacente.
Para garantizar mediciones reproducibles, los investigadores crearon grandes conjuntos de objetos que superaban la capacidad de la caché y después seleccionaron ubicaciones aleatorias en cada ronda, en lugar de buscar un conjunto de desalojo preciso para cada línea de memoria. También se utilizaron Durable Objects para mantener un contexto de ejecución de larga duración, mientras que los mensajes WebSocket permitieron restablecer los límites de tiempo de procesamiento y de solicitudes. Mediante pausas periódicas entre lotes de ejecución, fue posible mantener activo el aislamiento entre cinco horas y más de 20 horas.
Para lograr la proximidad entre el atacante y la víctima, el Worker atacante invocó al Worker víctima mediante fetch, lo que en la mayoría de los casos hizo que ambos se ejecutaran en el mismo proceso del mismo servidor de borde. Este método también permitió aprovechar los periodos de menor carga en los centros de borde para aumentar la estabilidad de las mediciones.
¿Qué cambió en la práctica en las defensas de Cloudflare?
Cloudflare introdujo varias modificaciones en lugar de depender de una única medida. V8 Sandbox pasó a formar parte de las capas de protección y pretende reducir la presencia de punteros sin procesar de 64 bits en grandes partes del montón de JavaScript. Esto dificulta la reutilización de algunos de los gadgets de confusión especulativa utilizados en la investigación, pero no constituye una solución completa contra los ataques Spectre, ya que podrían aparecer otros gadgets o formas que permitan acceder fuera de los límites de la memoria.
En septiembre de 2025, la empresa implementó un aislamiento dentro del proceso basado en Memory Protection Keys, o MPK. Esta tecnología divide la memoria en dominios de protección y cambia sus permisos de acceso con un coste reducido, de modo que el montón de cada aislamiento queda detrás de una barrera impuesta por el hardware. Esto impide la lectura directa entre los montones de los aislamientos en la que se basaba el ataque, pero no elimina todos los riesgos de Spectre; el número de dominios de protección es limitado y el sistema también requiere una gestión precisa del estado de las claves de protección.
Cloudflare también mejoró el mecanismo DyPrIs para gestionar operaciones de larga duración y cargas intensivas de entrada y salida. Esperar a que termine la invocación para aislar el script no es suficiente cuando una conexión WebSocket o un Durable Object puede mantener abierta la invocación durante horas. La empresa también está estudiando añadir el comportamiento de temporización remota a las señales de detección, especialmente cuando se repiten operaciones similares a temporizadores alrededor de partes con un uso intensivo de la computación, en lugar de considerar el tráfico de red asociado como ruido normal.
Limitaciones del resultado
La prueba se realizó contra Workers controlados por Cloudflare y por los investigadores, y no constituye una demostración de la intrusión en inquilinos reales. Además, según la aclaración de la empresa, la tasa de filtración más alta se obtuvo a costa de la precisión, y no se observaron indicios de explotación real durante los tres años anteriores. Por tanto, los resultados revelan una capacidad ofensiva viable en el modelo de aislamiento anterior y la importancia de combinar el aislamiento de procesos, la protección de la memoria impuesta por el hardware y la detección conductual continua.