Build1 publisher3 min readPublished
Cloudflare's own researchers broke the Spectre defense it shipped in 2021
An internal proof-of-concept leaked up to 12 bit/s at 99 percent accuracy inside production Workers by exploiting a limitation in Dynamic Process Isolation. Cloudflare says the gap is now closed.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction

What happened
- In 2021, Cloudflare assessed remote Spectre attacks against Cloudflare Workers.
- Based on the 2021 results, Cloudflare shipped a production defense called Dynamic Process Isolation (DyPrIs), which identifies maliciously looking scripts and isolates them into separate processes.
- Since 2021, newer techniques in the area of stabilizing Spectre attacks have been discovered, prompting Cloudflare to internally reassess the remote Spectre attack against its Workers production environment.
- Cloudflare built an updated proof-of-concept on the production environment to empirically assess the risk of Spectre attacks under production workloads.
- The research uncovered a limitation in the implementation of DyPrIs.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
Cloudflare has published research in which its own team rebuilt a remote Spectre attack against the live Workers environment, found a limitation in the implementation of Dynamic Process Isolation, and leaked data at up to 12 bit/s with 99 percent accuracy [4][5][6]. DyPrIs was the production defense Cloudflare shipped on the strength of its 2021 assessment of that same attack class, so the thing that retired the 2021 conclusion was Cloudflare's own updated proof-of-concept, not an incident [1][2].
The architecture is what makes this consequential rather than academic. Workers runs untrusted JavaScript at the edge and relies on V8 isolates so that tens of thousands of tenants can share a single operating-system process, each tenant with its own JavaScript heap [11]. Cloudflare is explicit that this is a trade: startup latency stays low and tenant density is far higher than full process isolation allows [12]. It is equally explicit about the cost, which is that one arbitrary read vulnerability inside a Worker process can produce cross-tenant leakage [14].
The surrounding defenses are not thin. Cloudflare lists automated V8 patch pipelines, a two-layered sandbox of Linux namespaces and seccomp filters, Cap'n Proto RPC, and the option to schedule particular scripts into separate process sandboxes [13]. Against in-process Spectre specifically, the runtime freezes local timers, disallows multithreading and shared memory, shuffles memory periodically, and isolates scripts that look malicious into their own processes [15]. During CPU-only execution, time is effectively frozen: neither Date.now() nor performance.now() gives a continuously advancing high-resolution clock [16]. An external attacker also has to work through activity on shared hardware, interrupts, context switches and coarse-grained timers [7].
All of that held in 2021 and none of it was enough by 2024. Cloudflare attributes the reassessment to newer published techniques for stabilizing Spectre attacks [3]. The structural weakness is in the shape of DyPrIs itself: it identifies scripts that look malicious and moves them [2]. A detector is a bet on the current state of an adversarial literature, and the research window here, 2024 into early 2025, sits roughly three to four years after the bet was placed [9][19].
Twelve bits per second sounds negligible until it is annualised. It works out to 5,400 bytes per hour [17], and at that ceiling a 256-bit secret is about 21 seconds of sustained leakage [18]. Bandwidth is not the limiting factor for credential-shaped targets.
Cloudflare's response was to improve DyPrIs and add two structural controls that do not depend on classification: the V8 Sandbox and an in-process isolation mechanism [8]. The company states the demonstrated attack is already mitigated in production by its Workers Runtime team, and that it found no indicators of active exploitation over the last three years [10]. The paper is co-authored with Albert Pedersen, Haocheng Xiao, Sam Ainsworth, Nigel Topham and Martin Schwarzl [9].
Worth watching: whether the published details let operators of other shared-process runtimes test their own detection-based mitigations, and whether the industry treats hardware-adjacent controls such as the V8 Sandbox as baseline rather than as an addition to heuristics [8]. Anyone running untrusted tenant code in a shared process on a security assessment written before these stabilization techniques existed has an expired document, not a defense.