Cloudflare has shown it can pull off a remote Spectre attack against its own edge computing platform, leaking a session token from one Workers tenant to another at up to 12 bits per second. The company says the attack is already patched in production, and it found no signs that anyone else used the technique first.
The research, published as a paper on arXiv and detailed on the Cloudflare blog, was carried out in 2024 and early 2025. It is a follow-up to work Cloudflare and TU Graz released in 2021, when they demonstrated a similar remote Spectre attack leaking data at about 120 bits per hour. The new variant runs 360 times faster.
What Spectre means for shared cloud hardware
Spectre is a class of CPU flaw that abuses speculative execution. When a processor guesses which branch of code will run next, it quietly executes instructions ahead of time. If the guess is wrong, the results are thrown away, but traces of the work stay behind in the CPU's cache. An attacker can read those traces by timing how fast certain memory locations respond.
Cloudflare Workers runs untrusted JavaScript on servers spread across the company's edge network. Tens of thousands of tenants can share a single operating-system process, with each tenant getting its own V8 isolate and its own JavaScript heap. That design keeps cold-start latency low and makes the platform cheap to run, but it also means one tenant's memory sits close to another's inside the same process.
Chaining four primitives into a working leak
The research group, which included Albert Pedersen, Haocheng Xiao, Sam Ainsworth, Nigel Topham, and Martin Schwarzl, had to solve four problems at once.
The first was finding a reliable Spectre gadget. The team built two: one that leaks compressed heap pointers, and one that abuses a speculative type confusion to read from an attacker-chosen 64-bit address. The second gadget leaned on a quirk of TypedArray, which at the time stored raw 64-bit pointers to its backing store even though most other V8 objects used 32-bit compressed pointers.
The second problem was signal amplification. A cache hit and a cache miss differ by only a few nanoseconds, and a remote timing source is noisy at microsecond scale. The team borrowed a technique from Google researchers Stephen Röttger and Artur Janc, exploiting the tree-based PLRU cache-replacement policy in L1 caches to make a single cache event produce a large, measurable timing gap.
Third came the remote timer. Workers deliberately freeze local clocks, so the researchers used a WebSocket connection to an external server serving high-resolution timestamps. With amplification in place, even that noisy channel was enough to tell a leaked 1 from a leaked 0.
Fourth, the attack needed co-location. Worker scripts execute on any edge server, so the attacker simply called the victim script with a fetch request. In most cases the scheduler spun up the victim isolate in the same process. Durable Objects then kept the victim alive: every incoming WebSocket message resets the runtime's CPU and subrequest limits, letting a single isolate run for five to more than 20 hours.
The Durable Objects loophole
The runtime normally resets a Worker's CPU budget and subrequest cap at the start of each HTTP invocation. A script that burns through its 30 seconds of CPU time gets killed. The researchers found a way around that by exploiting how Durable Objects handle WebSocket traffic: the runtime treats every incoming message as a fresh invocation, which resets both limits without ending the script.
That turned into a persistence trick with a catch. An isolate is single-threaded, so incoming WebSocket messages only get processed when the script hands control back to the event loop. If the thread stays blocked on synchronous code for more than 30 seconds, the runtime kills the isolate. The researchers worked around that too, yielding between bursts to keep a single isolate alive from five hours to more than a day. That gave them a persistent, bidirectional channel for running the attack over long stretches.
The keep-alive trick doubled as a disguise. DyPrIs only isolates a script after its invocation ends, and a WebSocket-heavy script that never ends simply never gets reviewed. The researchers noted that the long-lived invocation pattern also inflated the iTLB counts that DyPrIs uses to normalize its branch-misprediction signal, so the attack looked like ordinary network-bound traffic instead of a CPU side channel.
Why the existing defense missed it
Cloudflare's DyPrIs defense — a system that watches hardware performance counters and quarantines scripts that look like they are running a Spectre attack — had two blind spots, the researchers found.
The first is timing. DyPrIs only isolates a script after its invocation finishes. A Durable Object kept alive by WebSocket keep-alives can run for hours, so the leak completes long before isolation would kick in. The second is normalization. DyPrIs divides branch mispredictions by the number of instruction-translation-lookaside-buffer accesses. The WebSocket traffic that powers the remote timer also inflates iTLB activity, pushing the normalized ratio below the detection threshold. To the detector, the attack looked like an ordinary I/O-heavy Worker.
"We demonstrate that the production implementation of DyPrIs was insufficient," the researchers wrote in the paper.
Three layers of mitigation
Cloudflare says the attack no longer works against its production platform. The fix has three parts.
The V8 Sandbox, which was not yet running on Workers when the research was done, removes raw 64-bit pointers from large parts of the JavaScript heap. That neutralizes the specific type-confusion gadget the team used, because typed-array backing stores no longer expose the same pointer structure.
In September 2025, Cloudflare also deployed hardware-assisted in-process isolation based on Memory Protection Keys. Each isolate heap now sits behind a hardware-enforced access boundary; a memory access to a page protected with the wrong key is denied by the CPU itself. The company notes this blocks the straightforward cross-isolate heap read the research relied on, though it is not a full Spectre cure.
DyPrIs itself got an upgrade. Long-lived executions and I/O-heavy workloads are now treated as first-class security cases, and detection no longer waits for a script to finish. Cloudflare says it is also looking at whether remote timing behavior can be added as another detection dimension, since repeated timer-like I/O around compute-heavy sections is a telltale exfiltration pattern.
Why it matters for edge platforms
The disclosure lands as more compute moves off the big central cloud regions and into distributed edge infrastructure. Every provider that multiplexes untrusted code in shared processes, from serverless functions to CDN workers, faces the same underlying question: how much isolation is enough when a chip-level side channel can reach across a tenant boundary?
The research team's own conclusion is blunt: detection has to happen during execution, not after it, and it has to use a signal that I/O activity cannot suppress. The Hacker News coverage notes the tests ran on AMD EPYC Zen 2 and Zen 3 servers, with measurements taken at night when CPU utilization sat between 10% and 25 percent. Higher load slowed the leak but did not stop it, which means the attack stays feasible even on busy machines.
Cloudflare maintains a bug bounty program that pays for memory-safety bugs in the Workers runtime. The researchers also linked workerd, the open-source Workers runtime, for anyone who wants to test the boundaries themselves. For a platform that measures uptime in the hundreds of billions of requests a day, the message is a practical one: the defenses hold today, but the race to find the next gap never stops. Cloudflare's own history on this front, including its migration of the cdnjs library to its edge network, shows how seriously it takes the shared-infrastructure threat model. The company's edge platform work sits alongside its broader network services and cybersecurity coverage on this site.