Spectre Returns: An Attack on Cloudflare Workers Siphons Off JWTs at 12 Bits per Second

Translated by a model; the original is in Russian.

· Security
Researchers have demonstrated a remote Spectre attack against Cloudflare Workers, extracting a JSON Web Token from a neighboring Worker in production — 360 times faster than the 2021 demonstration.

cover.svg

Cybersecurity researchers have disclosed details of a remote Spectre-class attack on the Cloudflare Workers platform. In a production environment, they managed to extract a JSON Web Token (JWT) from a “neighboring” Worker at speeds of up to 12 bits per second with 99.16% accuracy. For comparison, a similar attack demonstrated in 2021 yielded only about 2 bits per minute — the new version turned out to be roughly 360 times faster.

The experiment was fully controlled: both the attacker and the victim belonged to the researchers themselves, and the JWT was deliberately placed in memory. The authors stress that no real customer data was ever accessed.

Why This Became Possible

Cloudflare Workers runs code from different tenants in separate V8 isolates within a single operating-system process, relying on language-level isolation rather than strict process separation — this reduces startup latency. The attack requires no V8 exploit or sandbox escape: it is enough for the attacker and the victim to end up in the same process.

Workers restrict local timing sources, “freezing” or coarsening timers, and deny scripts shared memory or multithreading. The researchers, however, found workarounds: a WebSocket served as a remote timer, while Durable Objects made it possible to keep an isolate alive for anywhere from five to more than twenty hours.

Particularly interesting is how they managed to fool Cloudflare's defensive mechanism — Dynamic Process Isolation (DyPrIs), which moves suspicious scripts into a separate process. A long-lived Durable Object call would finish before isolation kicked in, and intensive WebSocket I/O raised iTLB activity and “drowned” the branch-misprediction signal below the detector's firing threshold.

A Dispute Over Wording

Cloudflare calls this a limitation of a specific DyPrIs implementation. The paper's authors object: both weaknesses reflect fundamental limits of the detection approach itself, not an oversight. In their view, reliable detection must happen at runtime and rely on a signal that cannot be muffled by I/O operations.

Production tests were conducted on servers with AMD EPYC Zen 2 and Zen 3 processors running Linux. The measurements were run at night, at CPU loads of 10% to 25%, to obtain the best result; under high load the leak rate dropped, but the attack remained feasible.

What Cloudflare Did

The company states that the problem has already been remediated in production. Over three years, no signs of active exploitation have been found. The measures include an improved DyPrIs, integration of the V8 Sandbox (which limits transient access to 64-bit pointers), and in-process isolation based on Memory Protection Keys (MPK) that places Worker heaps behind hardware-protected keys. Modern x64 systems provide about 12 such keys, and Cloudflare combines them with the V8 sandbox and memory-layout rotation so that neighboring sandboxes do not share a single key.


Source: The Hacker News

Comments

Sign in, to comment.

  • No comments yet.