Une recherche en cybersécurité met en lumière une fuite JWT Spectre pouvant survenir dans Cloudflare Workers. Le scénario décrit ne vise pas les données clients : les auteurs indiquent avoir mené une expérience contrôlée aboutissant à l’exfiltration d’un JSON Web Token (JWT) placé volontairement dans la mémoire d’un Worker victime, dans un environnement de production.
Ce qui rend l’affaire particulièrement intéressante, c’est le contexte d’exécution : Workers fait tourner des codes de plusieurs clients dans des isolats V8 séparés, au sein du même processus système. Les détails publiés expliquent comment une faiblesse liée à la détection de l’isolation peut conduire à une fuite inter-tenant, à distance, en exploitant des signaux de performance.
Comment l’attaque Spectre a conduit à une fuite de JWT
Les chercheurs décrivent une démonstration de bout en bout avec deux Workers : un Worker attaquant et un Worker victime qu’ils contrôlent. Le JWT était intentionnellement stocké dans la mémoire de la partie victime, ce qui permettait de mesurer concrètement la fuite.
Le taux observé dans cette expérience atteint jusqu’à 12 bits par seconde, ce qui représente une accélération très nette par rapport à une démonstration précédente en 2021 (annoncée comme 360 fois plus rapide).
Selon les chercheurs, aucune donnée client n’a été consultée pendant l’expérimentation. L’objectif était de démontrer la mécanique d’un transfert de données malgré les mécanismes d’isolation mis en place.
Le rôle de l’exécution partagée et du modèle de menace
Cloudflare rappelle que Workers exécute du code multi-tenant en s’appuyant sur des isolats V8 distincts, tout en restant dans un même processus d’exploitation. L’idée générale est de limiter la latence au démarrage en évitant, autant que possible, une isolation strictement basée sur des processus séparés.
Dans ce cadre, une lecture mémoire au sein d’un même processus de Worker peut, dans certaines conditions, provoquer une fuite inter-tenant. L’attaque décrite nécessite que les deux Workers soient co-localisés : placés dans des isolats V8 différents, mais appartenant au même processus Worker.
Autre point important : les chercheurs précisent que l’attaque repose sur du code valide côté attaquant, exécuté dans son propre isolat. L’exécution de code natif n’entre pas dans le modèle de menace, et le mécanisme ne dépend pas d’une faille V8 ni d’une échappée du sandbox.
Pourquoi la détection n’a pas suffi : DyPrIs et les signaux de timing
Cloudflare Workers s’appuie sur un mécanisme d’isolation dynamique appelé Dynamic Process Isolation (DyPrIs). L’objectif est de détecter des comportements suspects et d’isoler davantage du code une fois une invocation terminée.
Les auteurs soutiennent cependant que la mise en œuvre en production présentait une limite : la détection DyPrIs ne couvrait pas parfaitement certaines conditions. L’équipe indique que des invocations durables, notamment via Durable Objects, peuvent rester actives assez longtemps pour continuer à s’exécuter avant que l’isolation ne soit appliquée.
Pour rendre l’attaque possible à distance, les chercheurs identifient deux sources potentielles de timing exploitables :
- WebSocket comme canal de communication fournissant un signal de temporisation utilisable à distance.
- Durable Objects pour conserver un isolat de Worker vivant pendant une durée pouvant aller de cinq heures à plus de vingt heures.
De plus, un facteur empirique joue un rôle : l’activité d’entrées/sorties (I/O) intensive via WebSocket augmenterait certaines activités matérielles, dont l’augmentation de l’activité de l’instruction translation lookaside buffer (iTLB). Cette dynamique réduirait un signal normalisé de mauvais branchement, utilisé par DyPrIs, jusqu’à passer sous son seuil de détection.
Accélération de la fuite : de “bits par minute” à “bits par seconde”
Le papier fait état d’une fuite atteignant jusqu’à 12 bits par seconde avec une précision de 99,16%. Pour donner l’ampleur par rapport à l’attaque antérieure, la recherche précédente mentionnait un ordre de grandeur autour de 2 bits par minute.
Les auteurs précisent aussi que le taux de fuite dépend du contexte système. Une charge plus élevée ralentirait l’exfiltration. Néanmoins, même sous charge élevée, des attaques plus lentes resteraient envisageables.
Ce que Cloudflare dit avoir corrigé en production
De son côté, Cloudflare indique avoir déjà atténué ce scénario dans l’environnement de production. Les changements évoqués couvrent plusieurs couches :
- Amélioration de DyPrIs pour renforcer les capacités de détection du mécanisme d’isolation existant.
- Intégration du V8 Sandbox, présentée comme une barrière supplémentaire limitant notamment l’accès transitoire à certains pointeurs 64 bits.
- Isolation en mémoire via MPK (Memory Protection Keys) à l’intérieur du processus : les heaps de Worker seraient placés derrière des clés de protection imposées par le matériel.
Cloudflare ajoute que sur des systèmes x64 modernes, environ 12 clés sont disponibles pour ce type de mécanisme, et que sa conception combine ces clés avec le V8 Sandbox et un agencement mémoire rotatif pour réduire le risque de partage de clé entre isolats proches.
Dans une description datant de septembre 2025, l’entreprise explique également qu’une assignation aléatoire de MPK seule pourrait piéger environ 92% des accès inter-isolats, car deux isolats peuvent recevoir la même clé. Le schéma rotatif serait utilisé pour combler ce “trou” dans le périmètre de menace concerné.
Timers figés, mémoire partagée non exposée : les protections déjà en place
Cloudflare souligne que Workers tente de réduire les sources de temporisation locales en gelant ou en grossissant les timers pendant l’exécution CPU. L’entreprise affirme aussi que les scripts Worker ne disposent pas de mémoire partagée ni de mécanismes de multithreading.
Autrement dit, l’attaque décrite s’appuie sur des signaux qui ne sont pas uniquement internes au processeur côté Worker, mais qui peuvent venir de canaux de communication comme WebSocket, ce qui explique pourquoi les chercheurs se sont intéressés à ce type de flux.
Mesures et conditions expérimentales
Les tests de mesure mentionnés dans le papier ont été effectués sur des serveurs Linux équipés de processeurs AMD EPYC Zen 2 et Zen 3. Pour tenter d’observer les meilleures conditions, les chercheurs annoncent avoir mené des mesures la nuit, avec une utilisation CPU comprise entre 10% et 25%.
Ils indiquent toutefois que dans des environnements plus chargés, la fuite devient moins rapide. Malgré cela, la recherche suggère que la faisabilité ne disparaît pas complètement.
Pourquoi ce cas remet le sujet sur la table
L’affaire s’inscrit dans une chronologie plus large. Le divulgation intervient près de cinq ans après une publication conjointe entre Cloudflare et TU Graz, qui démontrait un Spectre à distance sur Workers, ainsi que l’introduction de DyPrIs comme défense.
À l’époque, les conclusions rapportaient un taux de faux positifs autour de 0,61% et affirmaient que, statistiquement, DyPrIs offrait des garanties comparables à l’isolation par processus strict pour les attaques évaluées.
Dans le nouveau papier, les chercheurs affirment que les deux faiblesses observées reflètent davantage des limites fondamentales de l’approche de détection qu’un simple oubli de mise en œuvre. Ils proposent que la détection robuste devrait idéalement se faire pendant l’exécution et s’appuyer sur un signal difficilement “réductible” par des activités d’I/O.
Conclusion : une fuite JWT Spectre, mais des mitigations déjà en place
La fuite JWT Spectre décrite montre comment, dans un environnement d’exécution partagé comme celui de Cloudflare Workers, des signaux de timing et une fenêtre de détection peuvent suffire à exposer un token placé en mémoire. Le scénario présenté est contrôlé, ne porte pas sur des données clients, et met l’accent sur les conditions de co-localisation et sur le rôle des canaux de communication.
Cloudflare indique avoir déjà déployé des corrections en production : durcissement de DyPrIs, activation du V8 Sandbox et isolation interne basée sur MPK. L’entreprise affirme par ailleurs ne pas avoir trouvé d’indicateurs d’exploitation active sur une période de trois ans.
Source: https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html
