Cloudflare Workers, Spectre esfiltra un JWT a 12 bit al secondo

Un attacco remoto riuscito in ambiente di produzione

Ricercatori di sicurezza hanno dimostrato un attacco Spectre remoto contro Cloudflare Workers, capace di leggere un JSON Web Token dalla memoria di un Worker vittima. L’esperimento è stato rilevato il 19 agosto 2026.

La velocità massima raggiunta è stata di 12 bit al secondo, con un’accuratezza del 99,16%. Il risultato è circa 360 volte superiore a quello documentato nel 2021, quando un attacco analogo raggiungeva 2 bit al minuto.

La prova era composta da due Worker: uno controllato dall’attaccante e uno utilizzato come vittima. I ricercatori hanno inserito intenzionalmente il JWT nella memoria del secondo Worker e hanno poi tentato di ricostruirlo attraverso i segnali lasciati dall’esecuzione speculativa del processore.

Il test è avvenuto su infrastruttura Cloudflare reale, ma non ha coinvolto dati di clienti. Cloudflare ha inoltre dichiarato di non avere rilevato indicatori di sfruttamento attivo negli ultimi tre anni.

Perché l’isolamento dei Worker può esporre dati tra tenant

Cloudflare Workers esegue il codice dei diversi clienti all’interno di V8 isolate distinti. Gli isolate separano il contesto di esecuzione a livello di linguaggio, ma possono risiedere nello stesso processo del sistema operativo.

Questa architettura riduce la latenza di avvio rispetto all’uso di un processo separato per ogni Worker. Introduce però una superficie d’attacco diversa: una vulnerabilità microarchitetturale come Spectre può consentire di dedurre informazioni dalla memoria utilizzata da un altro isolate co-locato.

L’attaccante non deve eseguire codice nativo, compromettere V8 o uscire dal sandbox. È sufficiente che controlli codice valido nel proprio Worker e che questo venga collocato nello stesso processo del Worker vittima.

La fuga non consiste in una normale istruzione di lettura della memoria. Spectre sfrutta l’esecuzione speculativa e gli effetti indiretti lasciati nella cache e in altre strutture interne del processore. Ripetendo le misurazioni, l’attaccante può ricostruire bit di dati che non dovrebbe poter consultare.

In teoria, tra gli obiettivi possono rientrare token di autenticazione, chiavi o altri segreti temporaneamente presenti nell’heap di un tenant. La dimostrazione ha riguardato un JWT, non dati reali di clienti.

WebSocket e Durable Objects hanno aggirato le difese operative

Workers limita le funzioni di temporizzazione disponibili agli script. Durante l’esecuzione della CPU, alcune fonti temporali vengono congelate o rese meno precise; inoltre, gli script non dispongono di memoria condivisa né di multithreading.

I ricercatori hanno usato i WebSocket come orologio remoto. Il traffico e i tempi di risposta della connessione hanno fornito un riferimento sufficiente per distinguere i segnali prodotti dall’esecuzione speculativa, anche senza un timer locale ad alta precisione.

Un secondo elemento riguarda i Durable Objects. Questi componenti possono mantenere attivo un singolo isolate per periodi compresi tra cinque e oltre 20 ore. Una permanenza così lunga offre all’attaccante il tempo necessario per raccogliere molte misurazioni e migliorare progressivamente l’accuratezza.

L’architettura di rilevamento Dynamic Process Isolation, o DyPrIs, dovrebbe spostare gli script sospetti in un processo separato dopo la conclusione di un’invocazione. Secondo i test, però, un’invocazione prolungata di un Durable Object poteva continuare prima che l’isolamento venisse applicato.

L’uso intenso dei WebSocket creava inoltre molta attività nell’instruction translation lookaside buffer, o iTLB. Questo effetto riduceva il segnale dei branch misprediction, cioè delle predizioni errate dei salti, al di sotto della soglia usata da DyPrIs per identificare il comportamento anomalo.

Cloudflare ha descritto il problema come una limitazione dell’implementazione di DyPrIs. I ricercatori lo considerano invece una debolezza più strutturale: il rilevamento avveniva troppo tardi e si basava su un segnale che l’attività I/O poteva attenuare.

Prestazioni misurate su processori AMD

I test in produzione sono stati condotti su server Linux dotati di processori AMD EPYC Zen 2 e Zen 3. Le misurazioni sono state eseguite intenzionalmente durante la notte, quando l’utilizzo della CPU era compreso tra il 10% e il 25%.

Queste condizioni hanno favorito la raccolta del segnale. Con un carico superiore, la velocità di esfiltrazione diminuiva, ma l’attacco non diventava impossibile: procedeva semplicemente più lentamente.

Il precedente lavoro di Cloudflare e TU Graz, pubblicato nel 2021, aveva raggiunto 120 bit all’ora. Quella ricerca aveva introdotto DyPrIs come difesa e indicato un tasso di falsi positivi dello 0,61%, sostenendo che il meccanismo offrisse garanzie statistiche paragonabili all’isolamento rigido tra processi contro gli attacchi Spectre allora valutati.

La nuova dimostrazione mostra che quelle garanzie dipendevano dal modello di attacco e dalle condizioni operative considerate. Non dimostra che ogni Worker sia automaticamente esposto, ma conferma che l’isolamento in-process richiede difese multiple e un rilevamento continuo.

Le contromisure applicate da Cloudflare

Cloudflare ha dichiarato di avere mitigato l’attacco in produzione combinando tre meccanismi:

• una versione rafforzata di DyPrIs;
• l’integrazione del V8 Sandbox;
• l’isolamento in-process basato su Memory Protection Keys, o MPK.

Il V8 Sandbox limita l’accesso transitorio a puntatori a 64 bit. MPK aggiunge invece una protezione applicata dall’hardware, collocando gli heap dei Worker dietro chiavi specifiche.

Sui moderni sistemi x64 restano circa 12 chiavi utilizzabili per questo scopo. La piattaforma combina MPK, V8 Sandbox e una disposizione rotante della memoria, così da evitare che sandbox vicini condividano la stessa chiave.

Una descrizione delle misure pubblicata da Cloudflare nel settembre 2025 indicava che la sola assegnazione casuale delle chiavi avrebbe bloccato circa il 92% degli accessi tra isolate. Restava però una possibilità di collisione: due isolate potevano ricevere la stessa chiave. La disposizione rotante elimina questa lacuna nel modello di minaccia coperto dal sandbox.

La difesa non si basa quindi soltanto sull’identificazione dell’attacco. Anche se un segnale fosse mascherato dal traffico WebSocket o da un’invocazione di lunga durata, i controlli hardware e la separazione degli heap dovrebbero impedire l’accesso tra contesti.

Cosa devono sapere i clienti

Non sono state rese note versioni specifiche di Cloudflare Workers coinvolte, né è stato indicato un aggiornamento software da installare manualmente. La mitigazione dichiarata riguarda l’infrastruttura di produzione del provider.

Non è noto se il caso sia associato a un identificativo CVE o se sia presente nel catalogo Known Exploited Vulnerabilities della CISA. Non risultano inoltre una data di inserimento nel catalogo o una scadenza di remediation da comunicare agli amministratori.

Per i clienti, il rischio teorico riguarda soprattutto segreti mantenuti in memoria da Worker potenzialmente co-locati con codice ostile. È prudente ridurre la durata di vita dei token, limitarne i privilegi e prevedere la rotazione delle credenziali più sensibili. Queste misure non costituiscono però una correzione dell’isolamento sottostante.

Cloudflare non ha segnalato compromissioni attive. Di conseguenza, non ci sono indicatori pubblici specifici da cercare nei log dei clienti. Le organizzazioni dovrebbero comunque verificare accessi anomali ai servizi protetti dai JWT e ruotare i token se emergono attività sospette, senza attribuire automaticamente ogni anomalia a questo attacco.