Cloudflare mitigates 12-bit-per-second Spectre leak in Workers
Cloudflare has mitigated a remote Spectre attack against its Workers platform after researchers demonstrated extraction of a JSON Web Token from a co-located Worker at up to 12 bits per second and 99.16% accuracy. The controlled production experiment used an attacker Worker and a victim Worker operated by the researchers, with a JWT deliberately held in the victim's memory. The researchers said no customer data was accessed.
The reported rate is 360 times higher than a 2021 Workers attack demonstration, which reached 120 bits per hour, or 2 bits per minute. Cloudflare said it has improved Dynamic Process Isolation, known as DyPrIs, integrated the V8 Sandbox, and deployed Memory Protection Keys-based in-process isolation in production. The company said it found no indicators of active exploitation during the past three years.
How the cross-tenant attack worked
Workers runs multiple tenants' code in separate V8 isolates that can share an operating-system process. That design uses language-level isolation rather than strict process separation to reduce startup latency. A memory read in a shared Worker process can therefore create a path to cross-tenant leakage if the required conditions are met.
The attack required the malicious and victim Workers to be co-located in separate V8 isolates within the same process. The attacker needed to control valid code in its own isolate; native code execution, a V8 software vulnerability and a sandbox escape were outside the threat model. Researchers used WebSocket communication as a remote timing source because Workers restrict local timing by freezing or coarsening timers during CPU execution. They also used Durable Objects to keep one Worker isolate alive for between five and more than 20 hours.
In related coverage of cloud-hosted code security issues, the growing range of security issues around cloud-hosted code and automation shows why isolation boundaries require continuing scrutiny rather than one-time validation. In this case, the researchers found that a long-lived Durable Object invocation could continue before DyPrIs moved suspicious code into a separate process after invocation completion.
Detection limitation and production hardening
The researchers also found that WebSocket-heavy input/output increased instruction translation lookaside buffer activity. This reduced the normalized branch-misprediction signal used by DyPrIs beneath its detection threshold. Cloudflare characterized the problem as a limitation in its DyPrIs implementation, while the paper argued that the weaknesses showed fundamental limits of a detection approach whose signal can be suppressed by I/O activity.
Tests ran on Linux servers with AMD EPYC Zen 2 and Zen 3 processors. Measurements were intentionally made at night, when CPU utilisation was 10% to 25%, to obtain the best results. Higher load reduced the leakage rate, although the researchers said slower attacks remained feasible under high load.
Cloudflare's new controls combine improved DyPrIs with the V8 Sandbox, which limits transient access to 64-bit pointers, and MPK-based isolation for Worker heaps. Cloudflare said modern x64 systems typically leave about 12 protection keys available. Its design combines those keys with the V8 Sandbox and a rotating memory layout so nearby sandboxes do not share a key.
For businesses using serverless multi-tenant services, the incident is a reminder to assess where workloads may share processes, understand provider mitigation status, and avoid treating language-level separation as equivalent to every hardware-enforced isolation boundary.