Investigadores de ciberseguridad han publicado detalles sobre un ataque remoto basado en Spectre que logró provocar una fuga de JWT desde un Worker víctima en un entorno de producción. El experimento, realizado con Workers co-localizados, permitía extraer información desde la memoria del proceso y hacerlo a una velocidad alta para este tipo de vectores.
El hallazgo es relevante porque Cloudflare Workers ejecuta código de múltiples clientes en un modelo de aislamiento apoyado en mecanismos a nivel de lenguaje y de entorno de ejecución, no en separación estricta por procesos. Aunque la investigación afirma que no se accedió a datos de clientes, sí muestra que ciertas condiciones pueden facilitar la extracción de secretos desde memoria compartida a nivel de proceso.
Qué se filtró y a qué velocidad
Según la divulgación, el ataque consiguió filtrar un JSON Web Token (JWT) colocado intencionalmente en la memoria del Worker víctima. En el experimento completo, la tasa de filtración alcanzó hasta 12 bits por segundo. Además, los autores la comparan con un ataque anterior demostrado en 2021, señalando que esta nueva tasa habría sido aproximadamente 360 veces mayor.
En términos de precisión, el documento reporta una tasa de 99,16%, lo que sugiere que el procedimiento no era meramente teórico: el método podía recuperar el secreto con alta confiabilidad bajo las condiciones descritas.
Cómo funciona el experimento end-to-end
El modelo descrito es claro: un Worker atacante y un Worker víctima, ambos controlados por los investigadores, se ejecutaban en el mismo entorno con la posibilidad de estar co-localizados. El secreto (el JWT) se ubicaba en la memoria del Worker víctima.
La idea central es que una lectura de memoria dentro de un proceso que comparte contexto entre inquilinos puede derivar en filtración entre tenants. Para que el método funcionara según la investigación, el atacante debía lograr que ambos Workers quedaran en aislamiento de V8 distinto pero dentro del mismo proceso
Cloudflare, por su parte, remarca que el flujo no implicaba explotación del motor V8 ni un “escape” del sandbox como parte del escenario de amenaza. También indica que el código nativo queda fuera del modelo de ataque.
Por qué el aislamiento importa en Cloudflare Workers
Cloudflare explica que su infraestructura ejecuta código de múltiples clientes en isolas de V8 separadas dentro del mismo proceso del sistema operativo. La motivación de este diseño es práctica: reduce la latencia de arranque frente a una separación estricta por procesos.
En este contexto, el problema descrito se relaciona con cómo ciertos mecanismos de aislamiento pueden no impedir por completo lecturas laterales de memoria si se combinan condiciones específicas de ejecución. En otras palabras: el riesgo no es “todo o nada”, sino que depende de la interacción entre el modelo de aislamiento y la forma de medir y reconstruir el secreto.
El papel del temporizado remoto
Los investigadores señalan que la comunicación por WebSocket puede servir como fuente de temporizado remota. Ese detalle es clave porque muchos ataques tipo Spectre dependen de inferir diferencias temporales o señales observables para reconstruir información.
Además, mencionan que Durable Objects pueden mantener un Worker aislado vivo durante un periodo prolongado —desde cinco hasta más de 20 horas—, lo que facilita la continuidad del proceso necesario para recopilar señales y aumentar la probabilidad de éxito.
DyPrIs y el límite detectado
Para mitigar este tipo de vectores, Cloudflare utiliza Dynamic Process Isolation (DyPrIs). Este mecanismo aísla scripts sospechosos en un proceso separado después de que finaliza una invocación.
La investigación afirma que existe una ventana: una invocación de Durable Objects puede permanecer activa el tiempo suficiente para que el sistema todavía no ejecute la transición a aislamiento más estricto. En ese intervalo, el atacante podría intentar explotar la lógica subyacente.
También identifican que, cuando hay mucha actividad de entrada/salida (I/O) alrededor de WebSocket, aumenta la actividad de iTLB. Esto reduce la señal normalizada de branch misprediction usada por DyPrIs, llevándola por debajo del umbral de detección.
Aquí hay matices importantes. Cloudflare caracteriza el problema como una limitación del despliegue de DyPrIs, mientras que el documento plantea que las debilidades reflejan límites fundamentales del enfoque de detección y no únicamente fallos de implementación.
Qué dijo Cloudflare sobre la mitigación
Cloudflare sostiene que el ataque ya fue mitigado en producción antes de la divulgación pública. Para ello, indica mejoras y despliegues que refuerzan el aislamiento y dificultan la lectura efectiva de memoria.
Entre las acciones mencionadas se encuentran:
- Mejoras en DyPrIs para reforzar las capacidades de detección del mecanismo de aislamiento existente.
- V8 Sandbox para limitar accesos transitorios a punteros de 64 bits.
- Aislamiento en proceso basado en MPK (Memory Protection Keys), que coloca los montones (heaps) de los Workers detrás de claves de protección impuestas por hardware.
MPK, V8 Sandbox y el reparto de claves
En la descripción adicional compartida por Cloudflare, se afirma que en sistemas x64 modernos suele haber alrededor de 12 claves disponibles para este tipo de protección. El diseño combina esas claves con el V8 Sandbox y un esquema de disposición rotativa de la memoria.
La idea es evitar que dos “sandboxes” cercanos terminen compartiendo la misma clave, lo que reduciría drásticamente la posibilidad de acceso no autorizado por proximidad. En el mismo reporte de septiembre de 2025, se menciona que asignar claves al azar por sí solo “atraparía” aproximadamente 92% de accesos entre islas. El layout rotativo se usaría para cerrar la brecha restante en el modelo de amenaza cubierto dentro del sandbox.
Resultados experimentales y condiciones de prueba
El documento indica que las pruebas de producción se llevaron a cabo en servidores Linux con procesadores AMD EPYC Zen 2 y Zen 3. Los investigadores también describen que midieron en horarios nocturnos, con utilización de CPU entre 10% y 25%, buscando condiciones que ofrecieran el mejor escenario para observar resultados.
Curiosamente, afirman que una carga del sistema más alta reduce la tasa de filtración. Sin embargo, recalcan que el ataque lento podría seguir siendo viable bajo carga elevada.
Comparación con investigación previa
La divulgación llega casi cinco años después de un trabajo publicado por Cloudflare y TU Graz, en el que se mostró un ataque Spectre remoto contra Workers con una tasa aproximada de 120 bits por hora y se introdujo DyPrIs como defensa.
En aquel artículo inicial se reportó una tasa de falsos positivos de 0,61%. También se concluyó que, estadísticamente, DyPrIs ofrecía garantías equivalentes a las de una separación estricta por procesos para las evaluaciones Spectre consideradas entonces.
Qué implica esto para quienes ejecutan código en la nube
Más allá de los detalles técnicos, el caso refuerza una lección: incluso con aislamiento a nivel de lenguaje y con defensas dinámicas, los riesgos pueden surgir cuando la detección depende de señales que pueden alterarse por el patrón de actividad de entrada/salida y temporizado.
La investigación también sugiere que una detección robusta debería ocurrir durante la ejecución y basarse en señales difíciles de suprimir mediante actividad de I/O. En esa línea, el debate se desplaza de “si el aislamiento existe” hacia “qué tan resistente es la telemetría de detección bajo condiciones realistas”.
Conclusión
Los investigadores describen una fuga de JWT lograda mediante un ataque Spectre remoto que funcionó cuando un Worker atacante y un Worker víctima estaban co-localizados en el mismo proceso, aunque con islas V8 separadas. La velocidad reportada —hasta 12 bits por segundo— hace que el resultado destaque frente a un trabajo previo.
Cloudflare, por su parte, afirma haber mitigado el problema en producción mediante mejoras en DyPrIs, el V8 Sandbox y aislamiento en proceso basado en MPK. El caso deja claro que la seguridad en entornos multi-tenant exige combinar aislamiento, endurecimiento del runtime y mecanismos de detección que no dependan de señales fácilmente degradables.
Fuente: https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html
