Cloudflare has published a revisit of remote Spectre attacks against Cloudflare Workers, carried out by its own researchers Albert Pedersen and Haocheng Xiao with Sam Ainsworth and Nigel Topham of the University of Edinburgh and Martin Schwarzl.

They put a JWT inside a victim Worker and read it out, bit by bit, from a different tenant's code — reliably leaking up to 12 bits per second at 99% accuracy, in the production environment.

Cloudflare says the attack is already mitigated, and that it found no indicators of active exploitation over the last 3 years.

Why Workers are built this way

Cloudflare Workers runs code from many customers inside separate V8 isolates within the same operating-system process. That is language-level isolation rather than process isolation, and it is a deliberate trade: processes are expensive to start, isolates are nearly free, and near-zero cold starts are the product.

The consequence is that a memory read inside a shared Worker process can cross a tenant boundary. Everything below follows from that one architectural choice, which is not a mistake so much as a bet.

What makes this attack interesting

Not the Spectre part. The plumbing around it.

Workers deliberately do not give you a high-resolution timer, and Spectre needs one to tell a cache hit from a miss. The researchers got one anyway, from outside: a WebSocket connection to an external server serving high-resolution timestamps turns out to be enough. The clock does not have to be in the sandbox if the network can carry one in.

Even then the signal is nanoseconds and the timer is noisy. So they amplified it, using the tree-PLRU cache replacement policy to stretch the timing difference from nanoseconds into microseconds — a range a remote, jittery clock can actually resolve.

Co-location was arranged rather than waited for. Invoking the victim through fetch() typically lands both Workers on the same edge server and in the same process, and Durable Objects plus WebSocket keep-alives held the position open.

The detection bypass is the lesson

Cloudflare already had a defence for exactly this: Dynamic Process Isolation, which watches hardware performance counters for the branch-misprediction signature of a Spectre attack and moves the offending script into its own process.

It was defeated twice over, and neither was a clever cryptographic trick.

First, DyPrIs only isolates a script after its invocation completes — so the researchers kept a single invocation open for hours with a WebSocket keep-alive, and the isolation step simply never arrived. Second, the remote timer is I/O-heavy, which inflated instruction-TLB activity and dragged the normalised branch-misprediction ratio below the detection threshold. The noise the attack needed to work also happened to hide it.

That is a general lesson worth taking away from a very specific bug: a control that triggers at the end of an operation is not a control against an operation that does not end. The same shape shows up in session timeouts, in scan-on-close antivirus, and in any cleanup step an attacker can simply decline to reach.

What actually fixed it

Software mitigations narrowed it; hardware closed it.

The V8 Sandbox was integrated to remove raw 64-bit pointers from large parts of the heap, killing the specific gadgets this work relied on — one of which read TypedArray backing stores that used to hold raw pointers. DyPrIs was retuned to treat long-lived executions and I/O-heavy workloads as suspicious in their own right.

The decisive change was Memory Protection Keys, deployed in September 2025. Each isolate heap now sits behind a hardware-enforced access boundary, and a memory access to a page tagged with the wrong key is refused by the CPU. Speculative execution does not get a vote. That is what removes the straightforward cross-isolate heap read the attack was built on.

Software mitigation against a speculative-execution bug is a negotiation with the processor. Hardware enforcement is not, which is the same reason SCTPhantom's container escape mattered — boundaries hold only as far down the stack as they are actually enforced.

What to take from it if you run on shared infrastructure

  • Know which isolation you are buying. Process, VM and language-level isolation are sold with similar words and are not the same guarantee. It is a question worth putting to a vendor in writing.
  • Rate is a real defence. 12 bits per second is about a byte and a half — enough for a token given time, useless for a database. Slow exfiltration is still exfiltration, but scale matters when you are triaging.
  • Short-lived credentials help here specifically. A secret that expires in minutes is a poor target for a channel measured in bits per second.
  • Audit any control that fires on completion. That is the transferable part of this research.

What is not established

  • Whether anyone else found it. Cloudflare reports no indicators of exploitation over three years, which is an absence of evidence.
  • Whether other serverless platforms are affected. The architecture is not unique to Cloudflare; nobody has published equivalent testing elsewhere.
  • What the practical ceiling is. 12 bit/s was achieved in a research setup with co-location engineered on purpose.