A JWT Walks Out of a Cloudflare Worker at 12 Bits a Second

Researchers have disclosed a remote Spectre attack against Cloudflare Workers that leaked a JSON Web Token from a co-located Worker in the production environment at up to 12 bits per second ^[1]. That is 360 times the rate of the 2021 attack that Cloudflare and TU Graz published alongside Dynamic Process Isolation (DyPrIs), the detection mechanism offered at the time as a statistical substitute for strict process isolation ^[1][17][18].

The design under test is the reason Workers start fast: code from multiple tenants runs in separate V8 isolates inside the same operating-system process, with language-level isolation standing in for a process boundary ^[5]. Cloudflare's own framing is that a memory read inside a shared Worker process can lead to cross-tenant leakage, and the attack requires attacker and victim to land in separate isolates in the same process ^[6]. Nothing exotic is needed above that. The attacker runs valid code in its own isolate; native code execution is outside the threat model, and the attack does not depend on a V8 bug or a sandbox escape ^[7].

Two supposed obstacles were worked around rather than broken. Workers freeze or coarsen timers during CPU execution and expose neither shared memory nor multithreading ^[8], so the researchers used WebSocket communications as a remote timing source, and Durable Objects to keep a single isolate alive for five to more than 20 hours ^[9]. DyPrIs moves suspicious scripts into their own process after an invocation finishes, and a long-lived Durable Object invocation can simply keep running before that happens ^[10]. Separately, WebSocket-heavy I/O raised instruction TLB activity, pushing the normalized branch-misprediction signal DyPrIs relies on below its detection threshold ^[11].

That distinction matters more than the leak rate. Cloudflare called the problem a limitation of its DyPrIs implementation; the paper says the two weaknesses are fundamental limits of the detection approach, not oversights, and argues robust detection has to happen during execution using a signal that I/O activity cannot suppress ^[12][13]. The researchers' summary is blunt: "We demonstrate that the production implementation of DyPrIs was insufficient" ^[4].

The numbers deserve context. Tests ran on Linux servers with AMD EPYC Zen 2 and Zen 3 processors, and the researchers deliberately measured at night, when CPU utilization sat between 10% and 25%, to get the best possible result ^[14]. Higher load cut the leakage rate, though slower attacks stayed feasible ^[15]. The headline figure is up to 12 bits per second at 99.16% accuracy, against 2 bits per minute in 2021 ^[16]. In per-hour terms that is roughly 43,200 bits versus 120 ^[25]. The experiment was end-to-end but self-contained: both the attacker and victim Workers belonged to the researchers, the JWT was planted in the victim's memory, and the paper states no customer data was accessed ^[2].

Cloudflare says the attack is already mitigated in production and that it found no indicators of active exploitation over the last three years ^[3]. The fixes, published as Workers hardening in September 2025, are improved DyPrIs detection, the V8 Sandbox to limit transient access to 64-bit pointers, and MPK-based in-process isolation putting Worker heaps behind hardware-enforced protection keys ^[3][19][20]. Cloudflare says modern x64 systems leave about 12 keys available, so it combines them with the V8 Sandbox and a rotating memory layout to stop neighbouring sandboxes sharing a key ^[21]. By its own September 2025 accounting, random key assignment alone would trap about 92% of cross-isolate accesses, leaving roughly 8% uncovered, which is what the rotating layout is there to close ^[22][24].

Worth watching: whether the 2021 conclusion that DyPrIs matched process isolation statistically ^[18] gets restated for the improved version, and on what evidence; and whether the key-count ceiling of about 12 ^[21] constrains density as Cloudflare packs more tenants per machine.