Cloudflare Workers: Spectre exfiltra un JWT a 12 bits por segundo

Un ataque remoto exitoso en un entorno de producción

Investigadores de seguridad han demostrado un ataque Spectre remoto contra Cloudflare Workers capaz de leer un JSON Web Token de la memoria de un Worker víctima. El experimento se detectó el 19 de agosto de 2026.

La velocidad máxima alcanzada fue de 12 bits por segundo, con una precisión del 99,16 %. El resultado es aproximadamente 360 veces superior al documentado en 2021, cuando un ataque similar alcanzaba 2 bits por minuto.

La prueba constaba de dos Workers: uno controlado por el atacante y otro utilizado como víctima. Los investigadores introdujeron intencionadamente el JWT en la memoria del segundo Worker y después intentaron reconstruirlo mediante las señales dejadas por la ejecución especulativa del procesador.

La prueba se realizó sobre infraestructura real de Cloudflare, pero no involucró datos de clientes. Cloudflare también declaró no haber detectado indicios de explotación activa durante los últimos tres años.

Por qué el aislamiento de los Workers puede exponer datos entre tenants

Cloudflare Workers ejecuta el código de distintos clientes dentro de V8 isolates independientes. Los isolates separan el contexto de ejecución a nivel del lenguaje, pero pueden residir en el mismo proceso del sistema operativo.

Esta arquitectura reduce la latencia de inicio frente al uso de un proceso independiente para cada Worker. Sin embargo, introduce una superficie de ataque diferente: una vulnerabilidad microarquitectónica como Spectre puede permitir deducir información de la memoria utilizada por otro isolate ubicado en el mismo proceso.

El atacante no necesita ejecutar código nativo, comprometer V8 ni escapar del sandbox. Basta con que controle código válido en su propio Worker y que este se ubique en el mismo proceso que el Worker víctima.

La fuga no consiste en una instrucción normal de lectura de memoria. Spectre aprovecha la ejecución especulativa y los efectos indirectos que quedan en la caché y en otras estructuras internas del procesador. Al repetir las mediciones, el atacante puede reconstruir bits de datos que no debería poder consultar.

En teoría, entre los objetivos podrían encontrarse tokens de autenticación, claves u otros secretos presentes temporalmente en el heap de un tenant. La demostración se realizó con un JWT, no con datos reales de clientes.

WebSocket y Durable Objects sortearon las defensas operativas

Workers limita las funciones de temporización disponibles para los scripts. Durante la ejecución de CPU, algunas fuentes temporales se congelan o pierden precisión; además, los scripts no disponen de memoria compartida ni de multithreading.

Los investigadores utilizaron WebSocket como reloj remoto. El tráfico y los tiempos de respuesta de la conexión proporcionaron una referencia suficiente para distinguir las señales producidas por la ejecución especulativa, incluso sin un temporizador local de alta precisión.

Un segundo elemento está relacionado con los Durable Objects. Estos componentes pueden mantener activo un único isolate durante periodos de entre cinco y más de 20 horas. Una permanencia tan prolongada ofrece al atacante el tiempo necesario para recopilar numerosas mediciones y mejorar gradualmente la precisión.

La arquitectura de detección Dynamic Process Isolation, o DyPrIs, debería trasladar los scripts sospechosos a un proceso separado después de finalizar una invocación. Sin embargo, según las pruebas, una invocación prolongada de un Durable Object podía continuar antes de que se aplicara el aislamiento.

El uso intensivo de WebSocket también generaba mucha actividad en el instruction translation lookaside buffer, o iTLB. Este efecto reducía la señal de los branch misprediction, es decir, las predicciones erróneas de saltos, por debajo del umbral utilizado por DyPrIs para identificar comportamientos anómalos.

Cloudflare describió el problema como una limitación de la implementación de DyPrIs. Los investigadores lo consideran, en cambio, una debilidad más estructural: la detección se producía demasiado tarde y dependía de una señal que la actividad de I/O podía atenuar.

Rendimiento medido en procesadores AMD

Las pruebas en producción se realizaron en servidores Linux equipados con procesadores AMD EPYC Zen 2 y Zen 3. Las mediciones se llevaron a cabo intencionadamente durante la noche, cuando el uso de CPU se situaba entre el 10 % y el 25 %.

Estas condiciones favorecieron la recopilación de la señal. Con una carga superior, la velocidad de exfiltración disminuía, pero el ataque no se volvía imposible: simplemente avanzaba más despacio.

El trabajo anterior de Cloudflare y TU Graz, publicado en 2021, había alcanzado 120 bits por hora. Aquella investigación introdujo DyPrIs como defensa e indicó una tasa de falsos positivos del 0,61 %, sosteniendo que el mecanismo ofrecía garantías estadísticas comparables a las del aislamiento estricto entre procesos frente a los ataques Spectre evaluados entonces.

La nueva demostración muestra que esas garantías dependían del modelo de ataque y de las condiciones operativas consideradas. No demuestra que todos los Workers estén expuestos automáticamente, pero confirma que el aislamiento in-process requiere múltiples defensas y una detección continua.

Contramedidas aplicadas por Cloudflare

Cloudflare declaró haber mitigado el ataque en producción mediante la combinación de tres mecanismos:

• una versión reforzada de DyPrIs;
• la integración de V8 Sandbox;
• el aislamiento in-process basado en Memory Protection Keys, o MPK.

V8 Sandbox limita el acceso transitorio a punteros de 64 bits. MPK añade una protección aplicada por hardware, colocando los heaps de los Workers detrás de claves específicas.

En los sistemas x64 modernos quedan aproximadamente 12 claves utilizables para este fin. La plataforma combina MPK, V8 Sandbox y una disposición rotatoria de la memoria para evitar que sandboxes cercanos compartan la misma clave.

Una descripción de las medidas publicada por Cloudflare en septiembre de 2025 indicaba que la asignación aleatoria de claves por sí sola habría bloqueado aproximadamente el 92 % de los accesos entre isolates. Sin embargo, seguía existiendo una posibilidad de colisión: dos isolates podían recibir la misma clave. La disposición rotatoria elimina esta deficiencia dentro del modelo de amenazas cubierto por el sandbox.

Por tanto, la defensa no depende únicamente de identificar el ataque. Aunque una señal quedara oculta por el tráfico WebSocket o por una invocación prolongada, los controles de hardware y la separación de los heaps deberían impedir el acceso entre contextos.

Qué deben saber los clientes

No se han dado a conocer versiones específicas de Cloudflare Workers afectadas ni se ha indicado ninguna actualización de software que deba instalarse manualmente. La mitigación anunciada afecta a la infraestructura de producción del proveedor.

No se sabe si el caso está asociado a un identificador CVE o si figura en el catálogo Known Exploited Vulnerabilities de la CISA. Tampoco constan una fecha de inclusión en el catálogo ni un plazo de remediation que los administradores deban conocer.

Para los clientes, el riesgo teórico afecta principalmente a los secretos mantenidos en memoria por Workers potencialmente ubicados junto a código malicioso. Es recomendable reducir la duración de vida de los tokens, limitar sus privilegios y prever la rotación de las credenciales más sensibles. Sin embargo, estas medidas no corrigen el aislamiento subyacente.

Cloudflare no ha informado de compromisos activos. Por ello, no existen indicadores públicos específicos que deban buscarse en los logs de los clientes. Aun así, las organizaciones deberían comprobar si existen accesos anómalos a servicios protegidos por JWT y rotar los tokens si detectan actividad sospechosa, sin atribuir automáticamente cualquier anomalía a este ataque.