Cloudflare's own team beat its Spectre defence and pulled 12 bits a second out of production

Cloudflare's researchers rebuilt the remote Spectre attack against Cloudflare Workers on the live platform and got it to leak up to 12 bit/s at 99% accuracy, after finding a limitation in the company's own production defence ^[1][2]. That defence, Dynamic Process Isolation, identifies maliciously looking scripts and moves them into separate processes, which is the same shape of answer most multi-tenant compute vendors give when asked about speculative execution ^[3].

The 2021 version of this story ended with DyPrIs shipping ^[3]. Techniques for stabilising Spectre attacks have improved since, so the team reassessed during 2024 and early 2025, building the proof of concept against the production environment rather than a lab bench so the risk could be measured under real workloads ^[4][5]. That distinction carries the argument, because the usual reason remote Spectre is dismissed as impractical is environmental noise: contention on shared hardware, interrupts, context switches, and deliberately coarse timers ^[6]. On Workers, time is effectively frozen during CPU-only execution, and neither Date.now() nor performance.now() gives a continuously advancing high-resolution clock ^[7]. There is no shared memory and no multithreading ^[8]. The platform also freezes local timers, periodically shuffles memory, and detects and isolates suspicious scripts ^[9].

12 bit/s is slow. It is also 1.5 bytes per second, or about 5.4 kB per hour if sustained ^[10], and roughly 21 seconds for a 256-bit secret ^[11]. Accuracy is the number that matters more than throughput, because a noisy channel forces redundancy that eats the rate, and 99% leaves very little to pay for.

The structural point is the tenancy model. Workers runs untrusted JavaScript with tens of thousands of tenants sharing one operating-system process, separated by V8 isolates and per-Worker heaps ^[12]. That is what keeps startup latency low and density high compared with full process isolation ^[13]. Cloudflare states the consequence plainly: a single arbitrary read inside a Worker process can lead to cross-tenant leakage ^[14]. The surrounding layers - automated V8 patch pipelines, a two-layered sandbox of Linux namespaces and seccomp filters, Cap'n Proto RPC, optional separate process sandboxes - do not address in-process Spectre, which the company describes as very hard to mitigate ^[15].

The fix list is the most useful part of the disclosure. Cloudflare improved DyPrIs, but it also integrated the V8 Sandbox and an in-process isolation mechanism to further reduce the risk of memory disclosure ^[16]. The heuristic got patched; the additions that were introduced alongside it are structural. Anyone whose isolation story rests on classifying tenant behaviour should read that ordering carefully, because a classifier has an evasion surface by construction, and an attacker who wants to stay in the shared process only has to avoid looking interesting.

Cloudflare says the demonstrated attack is already mitigated in production by countermeasures from the Workers Runtime team, and that it found no indicators of active exploitation over the last three years ^[17][18]. Both statements are single-sourced to the vendor and are not independently verifiable from the outside.

Worth watching in the paper, co-authored by Albert Pedersen, Haocheng Xiao, Sam Ainsworth, Nigel Topham and Martin Schwarzl ^[19]: what exactly the DyPrIs limitation was, and whether the in-process isolation mechanism costs measurable throughput or startup time, since density was the reason for shared-process tenancy in the first place ^[13]. The broader question is whether other runtimes that pack untrusted tenants into one process keep offering behavioural detection as a sufficient answer now that a vendor has published the rate at which its own detection can be walked around.