The quick and weird summary

Researchers pulled off a remote Spectre-style trick against Cloudflare Workers and squeezed a JSON Web Token (JWT) out of a neighbor process at an eyebrow-raising pace — up to 12 bits/sec. Before you panic and burn your browser, the experiment used a victim Worker and an attacker Worker that the researchers themselves controlled, and the secret JWT was planted on purpose. No customer data was reported accessed.

How the poking worked — and why it mattered

Cloudflare Workers run lots of tenants inside separate V8 isolates that share the same operating-system process. That’s great for speed, but it creates a situation where a clever memory read across those isolates can leak information. The attack didn’t rely on some exotic native code exploit or a sandbox escape — the attacker simply executed valid code inside its own isolate and exploited microarchitectural behavior to read bits out of the neighbor’s memory.

Two practical levers made the attack possible: long-lived Worker activity and remote timing channels. Durable Objects kept an isolate alive for hours (five to 20+ hours in tests), and WebSocket traffic acted like a remote clock to time microarchitectural effects. Those two together let the researchers keep a “spy” running long enough to extract data. They also found that heavy WebSocket I/O messes with the CPU’s translation buffers and can blunt Cloudflare’s detector, lowering the signal DyPrIs looks for.

Testing was done on Linux boxes using AMD EPYC Zen 2 and Zen 3 CPUs, with measurements taken during low-load periods to get the clearest results. Higher server load slowed the leak down, but didn’t make it impossible. In their best runs the team reported up to 12 bits/sec with about 99.16% accuracy — a huge jump from earlier remote Spectre demos.

So what did Cloudflare do?

Cloudflare shipped fixes and hardening in production. The short checklist: they tightened their process-isolation detector, dropped a sandbox layer into V8, and added hardware-assisted protections for heap memory. Together these changes aim to make it much harder for nearby isolates to snoop on each other.

  • DyPrIs detection was improved to catch suspicious behavior earlier.
  • V8 Sandbox limits transient access to sensitive pointers.
  • MPK-based in-process isolation puts Worker heaps behind hardware protection keys and pairs that with a rotating memory layout so neighboring sandboxes don’t share the same key.

Cloudflare also noted that just randomly assigning hardware keys would have caught most cross-isolate reads, but the rotating layout removes the remaining gap for their threat model. They said they found no signs of this being actively exploited in the wild over the past few years.

Bottom line: this was a clever, controlled research demonstration that showed limits in a detection-first defense for shared-process environments. The fixes tighten things up, but the work is a reminder that shared-speed optimizations can sometimes shave away safety margins — and that attackers will try to turn clever timing and long-lived sessions into a data siphon. If you run cloud code, it’s a good excuse to check your own isolation and long-running session patterns.