Summary: A paper released on August 19, 2026 described a limitation in Cloudflare Workers’ DyPrIs defense and demonstrated a remote Spectre attack in production, leaking memory at up to 12 bits per second with 99% accuracy. Cloudflare shipped mitigation before publication and found no sign of exploitation during the preceding three years. The company also integrated the V8 Sandbox and deployed Memory Protection Key isolation.
The Spectre Question Serverless Builders Keep Revisiting
Back in 2021, Cloudflare took stock of remote Spectre attacks against Workers and rolled out a production defense named Dynamic Process Isolation (DyPrIs), which spots scripts that look malicious and moves them into processes of their own. In the years after, attackers kept finding fresh ways to make Spectre attacks stable. Wanting to know whether any of these newer techniques endangered the Workers production environment, Cloudflare ran another internal reassessment of the remote Spectre attack during 2024 and early 2025.
A paper released on August 19, 2026, laid out what they found: a limitation in how DyPrIs had been implemented, plus a working demonstration of a remote Spectre attack inside the production Workers environment — memory leaking reliably at up to 12 bit/s with 99% accuracy. The upside: mitigation had landed before the paper went public, and across the preceding three years Cloudflare saw no sign of anyone exploiting this in the wild.
For anyone building products or AI tools, the research is a nudge to remember that shared execution environments hide subtle security risks. Layered defenses alone don’t settle the matter — microarchitectural attacks can slip past assumptions, so reassessment has to be continuous.
How Workers Isolates Code, and Where Spectre Breaks In
On the edge, Cloudflare Workers executes untrusted JavaScript inside V8 isolates, which supply the language-level isolation. That setup lets tens of thousands of tenants live in a single operating-system process while every Worker keeps a JavaScript heap of its own. Startup latency stays low, and multi-tenancy runs far more efficiently than handing each tenant a full process.
The trade-off is that a single arbitrary read vulnerability inside a Worker process can leak data across tenants. Spectre ranks among the hardest of such vulnerabilities to counter, because it abuses speculative execution itself — a built-in property of CPUs.
Picture a hike to understand Spectre. Reaching a fork in the trail, you pick a path on a hunch. The right call saves time; the wrong one sends you back, though your footprints stay pressed into the mud. A CPU acts much the same way — a wrong branch prediction means the speculative results get thrown out, yet the cache state has already shifted. That leftover state is what an attacker leverages, encoding memory contents as differences in cache latency.
Timers, multithreading, and shared memory were already restricted on the Workers platform, which raises the difficulty of conventional Spectre attacks. Even so, the research team worked out ways around those restrictions.
Making the Attack Hold Up in Production
A successful side-channel attack from outside means clearing several hurdles in production: getting attacker and victim isolates scheduled onto the same edge server in the same process, securing a dependable remote timer, amplifying the signal despite production noise, and evicting cache data on demand.
Two kinds of Spectre gadgets did the work. One leaks compressed heap pointers — the isolate’s heap base address, for instance. The other turns speculative type confusion into reads from any attacker-crafted 64-bit pointer. When this research took place, Cloudflare Workers had yet to adopt the V8 Sandbox, so TypedArray still carried raw 64-bit backing store pointers — exactly what the gadget went after.
Amplifying the signal made or broke the attack. A cache hit and a miss sit nanoseconds apart, while remote-timer noise runs from microseconds up to milliseconds. A technique discovered by Stephen Röttger and Artur Janc came to the rescue: it exploits the tree-based pseudo-least-recently-used (PLRU) replacement policy of L1 caches, letting a specific memory-access pattern blow a single cache event’s timing difference up to a detectable level.
On the timing side, a single WebSocket to an external server handing out high-resolution timestamps was all it took. The paper compared several timer configurations and still reached sub-millisecond resolution on the median, even across sizable topological distances.
To make measurements repeatable, the team followed an approach Dougall Johnson described: allocate far more data than the cache can hold, then choose a new random location every round. The pigeonhole principle guarantees a randomly chosen cache line is almost never still cached — with a 256 KB L2 cache and 64 MB allocated, a random line has at most a 1/256 chance of surviving in cache. That sidesteps the costly business of building precise eviction sets.
Getting Attacker and Victim into the Same Process
The attack requires attacker and victim isolates to land in one process on one edge server. On Cloudflare Workers that part is effortless: have the attacker script call the victim with fetch("https://victim.example"), and the scheduler will normally spin up an instance of the victim worker inside that very process. Repeated subrequests then keep the victim isolate alive.
Working Around the Resource Limits
Workers caps each invocation at things like 30 seconds of CPU time and 1,000 subrequests. To stretch a single isolate across hours, the team leaned on Durable Objects: every incoming WebSocket message counts as a fresh invocation and resets the limits, so a steady stream of keep-alive messages held a persistent, bi-directional channel open. One catch — the isolate is single-threaded, so keep-alive messages only get processed while the script yields to the event loop. Let the thread stay blocked past 30 seconds and the runtime kills the isolate. Yielding at regular intervals kept isolates alive for anywhere from five to over 20 hours.
Assembling the Full Chain
The finished attack wired tree-based PLRU amplification into measurement loops, with every iteration rebuilding the cache state to stack up more timing difference. Run end-to-end in production, it pulled a JWT token out of a victim Worker bit by bit — a leakage rate of up to 12 bit/s at over 99% accuracy. Faster rates were possible, at the cost of accuracy.
How the Attack Slipped Past DyPrIs
DyPrIs monitors hardware performance counters and moves a script into a process of its own as soon as its behavior resembles a Spectre attack. Two things kept the attack out of view:
- Timing: A script gets isolated by DyPrIs only once its invocation has finished. Thanks to the Durable Object keep-alive trick, one invocation stretched over hours, letting the leak finish well before isolation could ever kick in.
- Normalization: DyPrIs divides branch mispredictions by the count of iTLB accesses. The WebSocket traffic serving as the remote timer pumped up iTLB activity, pushing the normalized ratio beneath the detection threshold — the attack read as just another I/O-heavy Worker.
The Fixes Cloudflare Shipped, and Lessons for Builders
This research drove three changes at Cloudflare: DyPrIs was improved, the V8 Sandbox was integrated, and an in-process isolation mechanism built on Memory Protection Keys (MPK) went into deployment in September 2025. With MPK, a process can split its memory into protection domains and flip access rights at little cost, keeping one isolate’s heap out of reach of every other isolate sharing the process.
By stripping raw 64-bit pointers from much of the JavaScript heap, the V8 Sandbox makes those particular speculative type-confusion gadgets harder to repurpose. It stops short of being a complete Spectre fix — other variants could still exist.
Several lessons stand out for product builders:
- Efficiency in shared execution environments is bought with isolation complexity. Low latency and high density are what V8 isolates deliver, yet microarchitectural attacks keep testing that bargain.
- Periodic reassessment is non-negotiable for defenses. DyPrIs did its job in 2021, but attack techniques move forward, and blind spots can hide in implementation details.
- A production demonstration persuades where theory cannot. Because the proof-of-concept ran in the real environment, Cloudflare could size the risk accurately and confirm the fixes actually worked.
Anyone designing multi-tenant AI or serverless services should read this research as a warning: no single layer of security carries the load by itself. Language-level isolation, process isolation, sandboxing, and continuous attack simulation have to operate as a set. And every time resources get shared in the name of performance, the worst-case data leakage risk needs to be understood up front.
Cloudflare’s closing position is that the attack has been mitigated and no active exploitation turned up. That is not a license to relax. Research into Spectre-class attacks keeps moving, and the next reassessment could uncover fresh gaps. Keep watching, keep the defenses stacked, and keep putting your own assumptions to the test.