Spectre Strikes the Edge: Cloudflare Workers Leak JWTs at 12 Bits/Second

Spectre Strikes the Edge: Cloudflare Workers Leak JWTs at 12 Bits/Second

Spectre Strikes the Edge: Cloudflare Workers Leak JWTs at 12 Bits/Second

Security researchers have disclosed a remote Spectre attack against Cloudflare Workers that successfully leaked a JSON Web Token (JWT) from a co-located Worker in production — at up to 12 bits per second. That rate is roughly 360 times faster than the original 2021 proof-of-concept, which managed only 120 bits per hour. The finding is a stark reminder that speculative-execution side channels, long considered a local-only threat, can be weaponized remotely against multi-tenant serverless platforms.

Cloudflare confirmed the research, stating that no customer data was accessed and that there were no indicators of active exploitation over the three years the technique was studied. The company has since rolled out a layered set of mitigations, but the episode offers a valuable lesson for anyone running code on shared infrastructure.

How The Attack Works

The attack relies on two Workers — an attacker-controlled Worker and a victim Worker — being co-located in separate V8 isolates within the same operating system process. Because both isolates share the same CPU and memory hierarchy, the attacker can attempt to read memory belonging to the victim through a Spectre-style speculative execution side channel.

Several findings made the attack practical where earlier attempts were not:

  • WebSocket communications as a remote timing source. The attacker used WebSocket messages to measure timing differences remotely, turning a local side channel into a network-observable one.
  • Durable Objects kept the isolate alive. By pinning the victim isolate to a Durable Object, researchers kept it resident for 5 to 20+ hours, giving the attack ample time to exfiltrate data bit by bit.
  • WebSocket I/O reduced iTLB activity. Sustained WebSocket traffic lowered instruction-TLB (iTLB) activity below the threshold that Cloudflare's existing detection mechanisms relied on, helping the attack stay under the radar.

The end result was a slow but steady leak of a JWT — a token that, in many real-world deployments, grants access to APIs and protected resources.

Bypassing Cloudflare's Defenses

Cloudflare had already introduced Dynamic Process Isolation (DyPrIs) in response to the 2021 research. DyPrIs dynamically moves isolates between processes to make co-location harder to predict and exploit. The new attack, however, found ways to work around it.

By manipulating WebSocket I/O activity, the researchers were able to reduce iTLB activity below the level DyPrIs uses to detect suspicious co-location patterns. In effect, the attack tuned its own behavior to avoid tripping the very signal designed to catch it. This cat-and-mouse dynamic is common in side-channel research: each mitigation raises the bar, but determined researchers often find a way to lower the noise floor.

Cloudflare's Response and Mitigations

Cloudflare responded with a multi-layered defense strategy rather than a single patch:

  • Improved Dynamic Process Isolation (DyPrIs). The detection thresholds and isolation logic were refined to account for the new attack's behavior.
  • Integrated V8 Sandbox. Cloudflare integrated the V8 engine's built-in sandbox, which adds a stronger in-process memory boundary between isolates.
  • Memory Protection Keys (MPK)-based in-process isolation. MPK provides hardware-enforced memory isolation within a process, making it far harder for one isolate to read another's memory even if a speculative-execution gadget is found.

Together, these measures significantly raise the cost and complexity of a successful attack. Cloudflare emphasized that the mitigations were deployed proactively and that the research was conducted under a coordinated disclosure process.

What Should You Do?

For most WAFNinja readers, the immediate risk is low — this is a sophisticated, platform-level attack rather than something you can trigger with a simple payload. Still, the disclosure carries practical lessons:

  • Treat JWTs as sensitive, short-lived credentials. Use short expiration times, rotation, and revocation. A leaked token should have a limited blast radius.
  • Don't rely on a single isolation boundary. Defense in depth matters. Even if your platform's isolation is compromised, your own application-level controls (least-privilege scopes, per-request authorization) should limit damage.
  • Stay informed about your platform's security posture. Multi-tenant serverless platforms are shared infrastructure. Follow vendor security advisories and understand what isolation guarantees they actually provide.
  • Keep secrets out of code and memory where possible. Minimize the sensitive data that lives in a Worker's memory at any given time.

The broader takeaway is that side-channel attacks are not going away. As serverless and edge computing grow, so does the incentive to break the isolation between tenants. Cloudflare's rapid, layered response is a good sign — but the research proves that the boundary between "theoretical" and "practical" side-channel attacks keeps shifting.

Sources