Cloudflare Workers Exposed to Remote Spectre Attack

Up to 12 bits per second of a secret JSON Web Token (JWT) were exfiltrated from a co‑located Cloudflare Worker in a production environment, the researchers reported — roughly 360 times faster than the remote Spectre demonstration published in 2021.

The attack demonstrated: remote Spectre across V8 isolates

Cybersecurity researchers carried out an end‑to‑end experiment using two Workers they controlled: an attacker Worker and a victim Worker. The JWT was intentionally placed in the victim's memory; the paper stated that no customer data was accessed. The researchers said their exploit achieved leakage of up to 12 bits per second at 99.16% accuracy, compared with 2 bits per minute in the earlier attack.

Cloudflare Workers runs code from multiple tenants in separate V8 isolates within the same operating‑system process, relying on language‑level isolation instead of strict process isolation to reduce startup latency. The attack requires the attacker and victim Workers to be co‑located in separate V8 isolates inside the same Worker process. The attacker controls valid code in its own isolate; the researchers specified that native code execution is outside the threat model and that the attack does not depend on a V8 software exploit or sandbox escape.

How the researchers bypassed timing and isolation controls

Cloudflare told the researchers that Workers restrict local timing sources by freezing or coarsening timers during CPU execution and do not expose shared memory or multithreading to Worker scripts. Despite those measures, the paper reported two practical channels that made the remote timing and long‑running execution needed for Spectre possible in production:

• WebSocket communications provided a remote timing source usable by the attacker.
• Durable Objects could keep a single Worker isolate alive for five to more than 20 hours, allowing long‑lived invocations.

The researchers also found that WebSocket‑heavy I/O increased instruction translation lookaside buffer (iTLB) activity, which reduced the normalized branch‑misprediction signal that Dynamic Process Isolation (DyPrIs) uses for detection, dropping it below DyPrIs’ detection threshold and enabling the covert channel.

Why DyPrIs failed to stop this instance

"We demonstrate that the production implementation of DyPrIs was insufficient," the researchers said in the paper. DyPrIs was introduced after the earlier 2021 work by Cloudflare and TU Graz, which reported a remote Spectre attack at about 120 bits per hour and concluded that DyPrIs statistically provided the same security guarantees as strict process isolation for the attacks evaluated then.

DyPrIs isolates suspicious scripts into a separate process after an invocation finishes. The researchers found two related weaknesses: long‑lived Durable Object invocations can continue running before isolation occurs, and I/O‑intensive workloads suppress the branch‑misprediction signal DyPrIs relies on. The paper framed these not merely as implementation oversights but as fundamental limitations of the detection approach — arguing that robust detection needs to run during execution and use signals that cannot be suppressed by I/O activity.

Cloudflare's mitigations: improved DyPrIs, V8 Sandbox, MPK isolation

Cloudflare said it has already mitigated the attack in production by improving Dynamic Process Isolation, integrating the V8 Sandbox, and deploying Memory Protection Keys (MPK)‑based in‑process isolation. Cloudflare added that it found no indicators of active exploitation over the last three years.

Cloudflare's September 2025 hardening measures include:

• Improved DyPrIs detection capabilities.
• V8 Sandbox to limit transient access to 64‑bit pointers.
• MPK‑based in‑process isolation that places Worker heaps behind hardware‑enforced protection keys; Cloudflare said modern x64 systems leave about 12 keys available for this purpose and that its design combines keys with the V8 Sandbox and a rotating memory layout to prevent nearby sandboxes from sharing a key.

Cloudflare also estimated that random MPK assignment alone would trap about 92% of cross‑isolate accesses because two isolates can receive the same key, and that the rotating memory layout removes that gap for the covered in‑sandbox threat model.

What this means for technologists and for cloud customers

Technologists and security teams: The researchers’ testbed ran on Linux servers with AMD EPYC Zen 2 and Zen 3 processors and used nighttime, low‑utilization conditions (10–25% CPU) to observe peak leakage. The paper noted higher system load reduced the leakage rate, although slower exfiltration remained feasible. Engineering teams operating multi‑tenant V8‑based platforms will need to assess long‑lived execution paths (for example, Durable Objects) and I/O patterns that could mask detection signals.

Cloud customers and procurement leaders: The experiment used co‑located Workers controlled by the researchers and did not access customer data, but it shows that secrets placed in process memory can be at risk when language‑level isolation shares an OS process among tenants. Customers should review threat models where long‑lived per‑tenant execution and WebSocket‑heavy workloads are required.

Nearly five years after the original Cloudflare/TU Graz paper introduced DyPrIs, this demonstration underscores the tension between performance‑oriented, in‑process isolation and speculative‑execution attacks that exploit microarchitectural behavior. Cloudflare has deployed a layered response — detection improvements, pointer‑width sandboxing, and hardware keying — but the researchers argue that detection approaches dependent on signals suppressible by I/O remain vulnerable during execution. That disagreement points to a concrete question left by the record: can real‑time detection be designed around a signal that I/O cannot mute, or must isolation shift back toward stricter process boundaries to close the class of Spectre‑style leaks?

Original reporting: https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html