Revisiting Remote Spectre Attacks on Cloudflare Workers: New Findings and Hardened Defenses

In 2021, Cloudflare assessed remote Spectre attacks against Cloudflare Workers. The assessment produced a defense now known as Dynamic Process Isolation (DyPrIs), which identifies malicious-looking scripts and isolates them into separate processes. Workers runs untrusted JavaScript in V8 isolates, allowing many tenants to share an OS process while keeping separate heaps. The runtime is protected by automated V8 patches, Linux namespaces and seccomp filters, Cap’n Proto RPC, and the option to schedule suspicious scripts in dedicated process sandboxes. Nonetheless, a single arbitrary read within a Worker process can lead to cross-tenant leakage, and Spectre is especially hard to mitigate because it relies on transient execution. In-process defenses therefore freeze local timers, disallow multithreading and shared memory, and depend on DyPrIs to detect and re-isolate risky scripts.

A remote Spectre attack must overcome several production obstacles:

• Guaranteeing co-location with a victim in the same OS process.
• Finding a usable remote timer; a WebSocket connection to a server returning high-resolution timestamps can serve this role.
• Amplifying the few-nanosecond cache-hit/miss difference; one method exploits the tree-based pseudo-LRU replacement policy in L1 caches to turn a single cache event into many measurable hits or misses.
• Maintaining a Spectre gadget that can transiently read 64-bit values out of bounds.

After the original assessment, newer techniques for stabilizing Spectre attacks were discovered. Cloudflare therefore re-evaluated the threat in its production Workers environment, building an updated proof-of-concept there. The research uncovered a limitation in DyPrIs’ implementation and demonstrated a remote Spectre attack that could leak up to 12 bit/s with 99% accuracy. The attack used a speculative type confusion to transiently follow an attacker-controlled 64-bit pointer; at the time, the V8 Sandbox was not yet deployed in Workers. Although no indicators of active exploitation were found, Cloudflare improved DyPrIs, integrated the V8 Sandbox, and added an in-process isolation mechanism to reduce memory-disclosure risk further. Those changes frame why a reassessment of the original design became necessary.

The persistent risk of Spectre attacks necessitates regular reassessment of security posture, as newer stabilization techniques have emerged since initial mitigations like Dynamic Process Isolation (DyPrIs) were deployed. While initial defenses effectively mitigated known vectors, evolving research indicates that attackers can overcome significant production hurdles—including coarse-grained timers, context switches, and shared hardware noise—to conduct reliable memory disclosure attacks.

To evaluate if these advanced techniques pose a realistic threat to production workloads, engineering teams must update their proof-of-concept (PoC) models. Empirically assessing Spectre under production constraints is essential because the microarchitectural state—specifically CPU caches—remains susceptible to transient execution artifacts. An effective empirical assessment must account for several critical factors:

• Remote Timer Reliability: Even in environments with restricted timers (e.g., non-advancing performance.now()), attackers may utilize co-located data center infrastructure or network-based timing sources like WebSockets to achieve sub-millisecond resolution.
• Signal Amplification: Due to noise in remote execution environments, attackers often employ techniques such as exploiting the tree-based Pseudo Least Recently Used (PLRU) cache-replacement policy. By manipulating access patterns to trigger specific L1 cache misses or hits, attackers amplify the signal of a single transient bit leak to a measurable threshold.
• Spectre Gadgets: Advanced PoCs now target specific language-level mechanisms, such as speculative type confusion. By mistraining branch predictors, an attacker can force the CPU to speculatively follow attacker-controlled 64-bit pointers, bypassing initial heap-based constraints.

The discovery of these techniques led to identified limitations in existing isolation mechanisms, eventually demonstrating that remote Spectre attacks can leak data with high accuracy (e.g., 99%) even under production conditions. Addressing these vulnerabilities requires a multi-layered approach beyond basic script isolation. Recommended architectural improvements include the integration of robust sandbox environments (such as the V8 Sandbox) and in-process isolation mechanisms designed to restrict memory access at the compiler or runtime level, thereby mitigating the impact of an arbitrary read even if a transient execution vulnerability is triggered.

Cloudflare Workers runs untrusted JavaScript at the edge using V8 isolates. Because each isolate has its own JavaScript heap, tens of thousands of tenants can share the same operating-system process. This provides language-level isolation with far lower startup cost than process-per-tenant enforcement, but it means the security boundary lives inside a shared address space.

Several defense layers surround the runtime:

• Automated V8 patch pipelines that pull in upstream security fixes before they are widely exploited.
• A two-layered OS sandbox using Linux namespaces and seccomp filters to restrict syscall access.
• Cap'n Proto RPC for capability-based communication between runtime components.
• Dynamic process isolation (DyPrIs) that schedules suspicious scripts into separate process sandboxes.

Still, a single arbitrary read vulnerability inside a worker process can cause cross-tenant leakage. The hardest class to mitigate is in-process Spectre, which abuses speculative execution. When a CPU mispredicts a branch, it transiently executes instructions whose architectural results are discarded, but microarchitectural state, such as cache lines, is not rolled back. An attacker can transiently read out-of-bounds memory, encode one bit into cache state, and later measure access latency to recover that bit.

Cloudflare deliberately restricts timing primitives: during CPU-only execution, Date.now() and performance.now() do not advance, and shared memory and multithreading are unavailable. However, remote timers work. A WebSocket to an external server serving high-resolution timestamps can provide sub-millisecond measurements. Combined with tree-based PLRU cache-replacement amplification, researchers reliably leaked data in production at up to 12 bits per second with 99% accuracy, by mistraining branch prediction and using a speculative type-confusion gadget to turn the leak into an arbitrary-address read.

For any multi-tenant isolate runtime, treat in-process Spectre as exploitable. Keep V8 patched, integrate the V8 Sandbox to reduce memory-corruption impact, freeze local high-resolution timers, forbid SharedArrayBuffer and worker threads, and isolate suspicious scripts into dedicated processes. Defense cannot rely on any single layer; the runtime must assume a transient-execution leak is possible and contain it.

In a production environment, a remote Spectre attack operates under continuous interference. Shared hardware resources introduce scheduling noise, interrupts and context switches desynchronize measurement windows, and coarse-grained timers obscure nanosecond-scale cache effects. Any viable attack must therefore treat the channel as lossy and amplify each transiently leaked bit until it survives system-level noise.

Cloudflare Workers deliberately remove the standard in-process workarounds for these obstacles. During CPU-only execution, Date.now() and performance.now() are frozen; no continuously advancing high-resolution clock exists. The platform also disallows SharedArrayBuffer and multithreading, eliminating the counter-thread timer technique. An attacker must instead assemble four primitives:

• guaranteed co-location with a victim tenant on the same physical core;
• a reliable remote timer, such as a WebSocket to a co-located server delivering high-resolution timestamps;
• a stable Spectre gadget enabling transient 64-bit out-of-bounds accesses; and
• signal amplification plus a cache-eviction primitive to convert a single bit into a measurable timing difference.

The proof-of-concept uses two gadget types. The first leaks compressed heap pointers, such as the isolate's heap base (root). Under pointer compression, most references are 32-bit, but TypedArray retains a raw 64-bit backing-store pointer. Mistraining a branch such as obj instanceof ObjP causes the CPU to transiently follow an attacker-influenced memory layout and cache one of two probe lines based on a selected bit from that pointer. The second gadget abuses speculative type confusion: by arranging two large objects so the type field and the read field land on different cache lines, evicting the type field widens the speculation window while the target field stays cached. The transient read then follows an attacker-crafted 64-bit pointer, converting the leak into an arbitrary-address read.

Because a cache hit versus miss differs by only nanoseconds, the attack amplifies the signal using the tree-based pseudo-LRU (PLRU) replacement policy in L1. PLRU organizes each cache set as a binary tree of least-recently-used pointers; a targeted access pattern keeps a line cached by touching its tree neighbor, so a single cache event expands into a burst of L1 hits or misses. With this amplification, a noisy remote timer becomes sufficient—the paper's measurements show reliable sub-millisecond median resolution with only a handful of samples.

The central empirical result is that the production Spectre defense, Dynamic Process Isolation (DyPrIs), has a measurable implementation limitation. DyPrIs identifies malicious-looking scripts and isolates them into separate OS processes. In a reassessment under real production workloads, the researchers demonstrated a remote Spectre attack that reliably leaked up to 12 bit/s with 99% accuracy in the Cloudflare Workers production environment. This attack ran despite production obstacles such as activity on shared hardware resources, interrupts, context switches, and coarse-grained timers.

The attack required solving three distinct problems. First, a reliable Spectre gadget had to work under the Workers runtime. The researchers used two gadget types: one leaked compressed heap pointers to recover the isolate heap base and locate an attacker-controlled array; the other leveraged a speculative type confusion to perform an arbitrary 64-bit read from an attacker-crafted pointer. At the time, the V8 Sandbox was not yet implemented, so TypedArray still stored a raw 64-bit backing-store pointer, which the gadget abused. The signal from the leak is a single cache event, so two additional primitives were required:

• Signal amplification: a cache hit versus a cache miss differs by nanoseconds, which is too small for a noisy remote timer. The researchers amplified the signal using the tree-based pseudo-LRU cache-replacement policy in L1 caches, so one cache event produced many L1 hits or misses.
• Remote timer: a WebSocket connection to an external server providing high-resolution timestamps was sufficient; sub-millisecond median resolutions were achieved even over larger topological distances.

The attack is already mitigated in production. Following the research, Cloudflare improved DyPrIs, integrated the V8 Sandbox, and added an in-process isolation mechanism to reduce the risk of memory disclosure. Importantly, the researchers found no indicators of active exploitation over the last three years, meaning the finding represents a defensive gap rather than evidence of an ongoing compromise.

Research conducted between 2024 and early 2025 by Albert Pedersen, Haocheng Xiao, Sam Ainsworth, Nigel Topham, and Martin Schwarzl identified a limitation in the existing Dynamic Process Isolation (DyPrIs) implementation within the Cloudflare Workers environment. The study demonstrated that, despite existing protections, a remote Spectre attack could reliably leak data at 12 bit/s with 99% accuracy. Critically, these findings were mitigated in production before the research paper was published.

To address the risks associated with speculative execution and transient instruction sequences, the platform implemented several defensive architecture updates:

• Improved DyPrIs: Refined logic for identifying and isolating scripts that exhibit suspicious, non-deterministic execution patterns, moving them into sandboxed processes.
• V8 Sandbox Integration: The implementation of the V8 Sandbox provides an additional layer of memory safety by ensuring that even if a renderer or worker process is compromised via an arbitrary read, the attacker remains constrained to the isolated sandbox memory rather than accessing the broader process heap.
• In-Process Isolation Mechanism: Introduced to limit the scope of potential memory disclosure, this mechanism further partitions resources, reducing the success rate of transient execution side-channel attacks.

These defense-in-depth strategies supplement existing controls such as the two-layered sandbox (Linux namespaces and seccomp filters), the freezing of high-resolution local timers, and the systematic prohibition of shared memory primitives like SharedArrayBuffer. By integrating the V8 Sandbox, the runtime successfully eliminates vulnerabilities where speculative type confusion could previously lead to arbitrary 64-bit pointer access. These updates ensure that even if an attacker successfully mistrains a branch predictor to bypass language-level isolation, the hardware-level and runtime-level sandboxing prevent the exfiltration of unauthorized memory segments, maintaining tenant isolation in high-density multi-tenant environments.