Cloudflare Workers

Revisiting Remote Spectre Attacks on Cloudflare Workers: What Builders Should Know

Cloudflare's 2024-2025 reassessment found a DyPrIs gap, demonstrating a remote Spectre attack at 12 bit/s with 99% accuracy. Learn what changed and what it means for multi-tenant…

Revisiting Remote Spectre Attacks on Cloudflare Workers: What Builders Should Know — article cover
On this page6 SECTIONS
  1. Why Spectre Still Matters for Serverless Platforms
  2. The Workers Security Model and Spectre
  3. How the Attack Works in Production
  4. Why DyPrIs Didn’t Detect It
  5. What Cloudflare Changed and What It Means for You
  6. Sources

Why Spectre Still Matters for Serverless Platforms

In 2021, Cloudflare assessed remote Spectre attacks against its Workers platform and shipped a production defense called Dynamic Process Isolation (DyPrIs), which identifies malicious-looking scripts and isolates them into separate processes. Since then, attackers have discovered newer techniques for stabilizing Spectre attacks. To understand whether these techniques posed a real threat to its Workers production environment, Cloudflare internally reassessed the remote Spectre attack in 2024 and early 2025.

The results, published in a paper on August 19, 2026, revealed a limitation in DyPrIs’s implementation. The team successfully demonstrated a remote Spectre attack in the production Workers environment, reliably leaking up to 12 bit/s with 99% accuracy. The good news: the attack was already mitigated before the paper’s release, and Cloudflare found no indicators of active exploitation over the previous three years.

For product builders and AI tool developers, this research is a reminder that shared execution environments carry subtle security risks. Even with multiple layers of defense, microarchitectural attacks can bypass assumptions and require continuous reassessment.

The Workers Security Model and Spectre

Cloudflare Workers runs untrusted JavaScript on the edge using V8 isolates for language-level isolation. Tens of thousands of tenants can share the same operating-system process, with each Worker having its own separate JavaScript heap. This design keeps startup latency low and allows efficient multi-tenancy compared to full process isolation.

However, this efficiency comes with a trade-off: a single arbitrary read vulnerability within a Worker process can lead to cross-tenant data leakage. Spectre is particularly hard to mitigate because it exploits the nature of speculative execution in CPUs.

To understand Spectre, think of hiking. At a fork in the trail, you predict which path to take. If you guess right, you save time. If you guess wrong, you turn back, but your footsteps remain in the mud. CPUs behave similarly: when a branch prediction is incorrect, the CPU discards the speculative results, but the cache state has already been altered. An attacker can use this residual state to encode memory contents into cache latency differences.

The Workers platform already restricts timers, multithreading, and shared memory, making traditional Spectre attacks harder. But the research team found ways to bypass these restrictions.

How the Attack Works in Production

To mount a successful side-channel attack in production, an external attacker must overcome several obstacles: ensuring attacker and victim isolates are scheduled on the same edge server and process, finding a reliable remote timer, amplifying the signal under production noise, and reliably evicting data from the cache.

The team used two types of Spectre gadgets. The first leaks compressed heap pointers, such as the isolate’s heap base address. The second leverages speculative type confusion to read from an arbitrary, attacker-crafted 64-bit pointer. At the time of the research, the V8 Sandbox was not yet implemented at Cloudflare Workers, and TypedArray still stored raw 64-bit backing store pointers, which the gadget exploited.

Signal amplification was critical. Cache hits and misses differ by only a few nanoseconds, but remote timers have noise on the order of microseconds to milliseconds. The team used a technique discovered by Stephen Röttger and Artur Janc that exploits the tree-based pseudo-least-recently-used (PLRU) cache replacement policy in L1 caches. By accessing memory in a specific pattern, an attacker can amplify the timing difference of a single cache event to a detectable level.

For the remote timer, a WebSocket connection to an external server serving high-resolution timestamps was sufficient. The paper evaluated several timer setups and achieved sub-millisecond resolution on the median, even over larger topological distances.

For repeatable measurements, the team used a method described by Dougall Johnson: allocate far more data than the cache can hold, then pick a fresh random location each round. Due to the pigeonhole principle, a randomly chosen cache line is almost certainly not cached. For a 256 KB L2 cache, allocating 64 MB leaves at most a 1/256 chance that a random line is still cached. This avoids the expensive process of building precise eviction sets.

Co-locating Attacker and Victim

For the attack to work, both attacker and victim isolates must be scheduled in the same process on the same edge server. On Cloudflare Workers, this is trivial: invoking the victim script from the attacker script with a fetch("https://victim.example") usually causes the scheduler to spin up an instance of the victim worker in the exact same process. The victim isolate can be kept alive by repeatedly making subrequests.

Defeating Isolate Resource Limits

Workers enforces limits like 30 seconds of CPU time and 1,000 subrequests per invocation. To keep a single isolate alive for hours, the team used Durable Objects, which treat every incoming WebSocket message as a new invocation that resets limits. By sending keep-alive messages, they maintained a persistent, bi-directional channel. One quirk: the isolate is single-threaded, so keep-alive messages are only processed when the script yields to the event loop. If the thread stays blocked for more than 30 seconds, the runtime kills the isolate. By yielding regularly, they kept isolates alive from five to over 20 hours.

Putting It All Together

The final attack combined tree-based PLRU amplification with measurement loops. Each iteration re-creates the cache state, adding more timing difference. The team demonstrated the full end-to-end attack in production, leaking a JWT token from a victim Worker bitwise. They achieved a leakage rate of up to 12 bit/s with over 99% accuracy. Higher rates are possible but with lower accuracy.

Why DyPrIs Didn’t Detect It

DyPrIs watches hardware performance counters and isolates a script into its own process once it looks like a Spectre attack. Two factors kept the attack under the radar:

  1. Timing: DyPrIs isolates a script only after its invocation finishes. The Durable Object keep-alive trick kept a single invocation open for hours, so the leak completed long before isolation would kick in.
  2. Normalization: DyPrIs normalizes branch mispredictions by the number of iTLB accesses. The remote timer’s WebSocket traffic inflated iTLB activity, dropping the normalized ratio below the detection threshold. The attack looked like an ordinary I/O-heavy Worker.

What Cloudflare Changed and What It Means for You

As a result of this research, Cloudflare improved DyPrIs, integrated the V8 Sandbox, and deployed an in-process isolation mechanism using Memory Protection Keys (MPK) in September 2025. MPK lets a process divide memory into protection domains and switch access rights cheaply, protecting each isolate’s heap from being accessible to others within the same process.

The V8 Sandbox removes raw 64-bit pointers from large parts of the JavaScript heap, making the specific speculative type-confusion gadgets harder to reuse. However, it is not a complete Spectre mitigation; other variants may still exist.

For product builders, several lessons stand out:

  • Shared execution environments trade efficiency for isolation complexity. V8 isolates offer low latency and high density, but microarchitectural attacks continuously challenge that assumption.
  • Defenses need periodic reassessment. DyPrIs was effective in 2021, but attack techniques evolve, and implementation details may have blind spots.
  • Production demonstrations are more convincing than theoretical analysis. Building a proof-of-concept in the real environment allowed Cloudflare to accurately assess risk and verify fixes.

If you’re designing multi-tenant AI or serverless services, this research underscores that security cannot rely on a single layer. Language-level isolation, process isolation, sandboxing, and continuous attack simulation must work together. And when you share resources for performance, you must understand the worst-case data leakage risk.

Cloudflare’s conclusion is that the attack is mitigated and no active exploitation was found. But that doesn’t mean you can relax. Spectre-class research continues, and the next reassessment might reveal new gaps. Stay vigilant, keep your defenses layered, and periodically test your own assumptions.

Sources

AI-assisted summary compiled from the sources above, reviewed by a human before publishing.

FOUND_THIS_USEFUL?

Support more practical AI articles, tutorials, and build notes.

BUY_ME_A_COFFEE
SHAREXEMAIL