Cloudflare Workers : Spectre exfiltre un JWT à 12 bits par seconde

Une attaque à distance réussie en environnement de production

Des chercheurs en sécurité ont démontré une attaque Spectre à distance contre Cloudflare Workers, capable de lire un JSON Web Token dans la mémoire d’un Worker victime. L’expérience a été détectée le 19 août 2026.

La vitesse maximale atteinte était de 12 bits par seconde, avec une précision de 99,16 %. Ce résultat est environ 360 fois supérieur à celui documenté en 2021, lorsqu’une attaque similaire atteignait 2 bits par minute.

La démonstration reposait sur deux Workers : l’un contrôlé par l’attaquant et l’autre utilisé comme victime. Les chercheurs ont intentionnellement placé le JWT dans la mémoire du second Worker, puis ont tenté de le reconstituer à partir des signaux laissés par l’exécution spéculative du processeur.

Le test a été réalisé sur une infrastructure Cloudflare réelle, mais n’a impliqué aucune donnée client. Cloudflare a également déclaré n’avoir détecté aucun indicateur d’exploitation active au cours des trois dernières années.

Pourquoi l’isolation des Workers peut exposer des données entre tenants

Cloudflare Workers exécute le code de différents clients dans des V8 isolates distincts. Ces isolates séparent les contextes d’exécution au niveau du langage, mais peuvent résider dans le même processus du système d’exploitation.

Cette architecture réduit la latence de démarrage par rapport à l’utilisation d’un processus distinct pour chaque Worker. Elle introduit toutefois une autre surface d’attaque : une vulnérabilité microarchitecturale telle que Spectre peut permettre de déduire des informations de la mémoire utilisée par un autre isolate colocalisé.

L’attaquant n’a pas besoin d’exécuter du code natif, de compromettre V8 ou de sortir du sandbox. Il lui suffit de contrôler du code valide dans son propre Worker et que celui-ci soit placé dans le même processus que le Worker victime.

La fuite ne repose pas sur une instruction classique de lecture mémoire. Spectre exploite l’exécution spéculative et les effets indirects laissés dans le cache ainsi que dans d’autres structures internes du processeur. En répétant les mesures, l’attaquant peut reconstituer des bits de données auxquels il ne devrait pas avoir accès.

En théorie, les cibles peuvent inclure des jetons d’authentification, des clés ou d’autres secrets temporairement présents dans le tas d’un tenant. La démonstration portait sur un JWT, et non sur des données client réelles.

Les WebSockets et les Durable Objects ont contourné les défenses opérationnelles

Workers limite les fonctions de temporisation accessibles aux scripts. Pendant l’exécution du code CPU, certaines sources temporelles sont figées ou rendues moins précises ; les scripts ne disposent par ailleurs ni de mémoire partagée ni de multithreading.

Les chercheurs ont utilisé les WebSockets comme horloge distante. Le trafic et les temps de réponse de la connexion ont fourni une référence suffisante pour distinguer les signaux produits par l’exécution spéculative, même sans timer local haute précision.

Un deuxième élément concerne les Durable Objects. Ces composants peuvent maintenir un isolate actif pendant des périodes comprises entre cinq et plus de 20 heures. Une durée aussi longue donne à l’attaquant le temps de recueillir de nombreuses mesures et d’améliorer progressivement la précision.

L’architecture de détection Dynamic Process Isolation, ou DyPrIs, est censée déplacer les scripts suspects vers un processus distinct après la fin d’une invocation. Selon les tests, toutefois, une invocation prolongée d’un Durable Object pouvait se poursuivre avant l’application de l’isolation.

L’utilisation intensive des WebSockets générait également une forte activité dans l’instruction translation lookaside buffer, ou iTLB. Cet effet réduisait le signal des branch mispredictions, c’est-à-dire des mauvaises prédictions de branchement, en dessous du seuil utilisé par DyPrIs pour détecter un comportement anormal.

Cloudflare a décrit le problème comme une limitation de l’implémentation de DyPrIs. Les chercheurs y voient plutôt une faiblesse plus structurelle : la détection intervenait trop tard et reposait sur un signal que l’activité d’E/S pouvait atténuer.

Performances mesurées sur des processeurs AMD

Les tests en production ont été menés sur des serveurs Linux équipés de processeurs AMD EPYC Zen 2 et Zen 3. Les mesures ont volontairement été réalisées de nuit, lorsque l’utilisation du CPU se situait entre 10 % et 25 %.

Ces conditions ont favorisé la collecte du signal. Avec une charge supérieure, le débit d’exfiltration diminuait, mais l’attaque ne devenait pas impossible : elle progressait simplement plus lentement.

Les travaux précédents de Cloudflare et de la TU Graz, publiés en 2021, avaient atteint 120 bits par heure. Cette étude avait introduit DyPrIs comme mécanisme de défense et indiqué un taux de faux positifs de 0,61 %, en affirmant que le mécanisme offrait, contre les attaques Spectre alors évaluées, des garanties statistiques comparables à une isolation stricte entre processus.

La nouvelle démonstration montre que ces garanties dépendaient du modèle d’attaque et des conditions opérationnelles retenues. Elle ne prouve pas que chaque Worker est automatiquement exposé, mais confirme que l’isolation in-process nécessite plusieurs mécanismes de défense ainsi qu’une détection continue.

Les contre-mesures appliquées par Cloudflare

Cloudflare a déclaré avoir atténué l’attaque en production en combinant trois mécanismes :

• une version renforcée de DyPrIs ;
• l’intégration du V8 Sandbox ;
• l’isolation in-process fondée sur les Memory Protection Keys, ou MPK.

Le V8 Sandbox limite l’accès transitoire aux pointeurs 64 bits. MPK ajoute une protection appliquée par le matériel, en plaçant les tas des Workers derrière des clés spécifiques.

Sur les systèmes x64 modernes, environ 12 clés restent utilisables à cette fin. La plateforme combine MPK, V8 Sandbox et une disposition rotative de la mémoire afin d’éviter que des sandbox voisins partagent la même clé.

Une description des mesures publiée par Cloudflare en septembre 2025 indiquait que la seule attribution aléatoire des clés aurait bloqué environ 92 % des accès entre isolates. Un risque de collision subsistait toutefois : deux isolates pouvaient recevoir la même clé. La disposition rotative élimine cette lacune dans le modèle de menace couvert par le sandbox.

La défense ne repose donc pas uniquement sur la détection de l’attaque. Même si un signal était masqué par le trafic WebSocket ou par une invocation de longue durée, les contrôles matériels et la séparation des tas devraient empêcher les accès entre contextes.

Ce que les clients doivent savoir

Aucune version précise de Cloudflare Workers concernée n’a été communiquée, et aucune mise à jour logicielle à installer manuellement n’a été indiquée. La mesure d’atténuation annoncée concerne l’infrastructure de production du fournisseur.

On ignore si le cas est associé à un identifiant CVE ou s’il figure dans le catalogue Known Exploited Vulnerabilities de la CISA. Aucune date d’ajout au catalogue ni échéance de remédiation à communiquer aux administrateurs n’a non plus été publiée.

Pour les clients, le risque théorique concerne principalement les secrets conservés en mémoire par des Workers potentiellement colocalisés avec du code malveillant. Il est recommandé de réduire la durée de vie des jetons, de limiter leurs privilèges et de prévoir la rotation des identifiants les plus sensibles. Ces mesures ne constituent toutefois pas une correction de l’isolation sous-jacente.

Cloudflare n’a signalé aucune compromission active. Il n’existe donc pas d’indicateurs publics spécifiques à rechercher dans les journaux des clients. Les organisations devraient néanmoins vérifier les accès anormaux aux services protégés par des JWT et faire tourner les jetons en cas d’activité suspecte, sans attribuer automatiquement toute anomalie à cette attaque.