Cybersecurity researchers have revealed details of a remote Spectre attack targeting Cloudflare Workers that successfully extracted a JSON Web Token from a co-located Worker in the production environment at speeds reaching 12 bits per second—360 times faster than an earlier attack demonstrated in 2021. The end-to-end experiment used both an attacker Worker and a victim Worker controlled by the research team, with the JWT deliberately positioned in the victim's memory. The research paper clarified that no customer information was compromised during testing.
The production tests ran on Linux servers equipped with AMD EPYC Zen 2 and Zen 3 processors, with researchers intentionally conducting measurements at night when CPU utilization sat between 10% and 25% to capture the best possible outcomes. The paper documented leakage reaching up to 12 bits per second at 99.16% accuracy, a dramatic increase from the 2 bits per minute achieved in the prior attack—itself equivalent to 120 bits per hour reported nearly five years ago when Cloudflare and TU Graz first published research on remote Spectre attacks against Workers. Higher system load decreased the leakage rate, though the researchers noted that slower attacks remained possible even under heavy load conditions.
According to the researchers, "the production implementation of DyPrIs was insufficient." The team identified two key weaknesses: WebSocket communications could serve as a remote timing source, while Durable Objects could maintain a single Worker isolate alive for five to more than 20 hours. The researchers also discovered that WebSocket-heavy input/output activity boosted instruction translation lookaside buffer activity, which pushed the normalized branch-misprediction signal used by DyPrIs below its detection threshold. Cloudflare characterized the issue as a limitation in its DyPrIs implementation, while the paper argued the two weaknesses represented fundamental limitations of the detection approach rather than simple implementation oversights.
The attack works because Cloudflare Workers runs code from multiple tenants in separate V8 isolates within the same operating-system process, depending on language-level isolation instead of strict process isolation to cut down startup latency. A memory read within a shared Worker process can trigger cross-tenant leakage, the company explained. The attack demands that the attacker and victim Workers be co-located in separate V8 isolates within the same Worker process, with the attacker controlling valid code in its own isolate—native code execution falls outside the threat model, and the attack doesn't require a V8 software exploit or sandbox escape. The earlier 2021 paper reported a 0.61% false-positive rate and concluded that DyPrIs statistically delivered the same security guarantees as strict process isolation against the Spectre attacks evaluated at that time.
Cloudflare confirmed the attack has already been mitigated in production following improvements to Dynamic Process Isolation, integration of the V8 Sandbox, and deployment of Memory Protection Keys-based in-process isolation, adding that it found no indicators of active exploitation over the past three years. The company published additional Workers hardening measures in September 2025. The deployed mitigations include improved DyPrIs to enhance detection capabilities, V8 Sandbox to limit transient access to 64-bit pointers, and MPK-based in-process isolation that places Worker heaps behind hardware-enforced protection keys—with modern x64 systems leaving about 12 keys available for this purpose. Cloudflare's design combines the keys with the V8 Sandbox and a rotating memory layout to prevent nearby sandboxes from sharing a key, with the September 2025 description noting that random MPK assignment alone would trap about 92% of cross-isolate accesses, while the stricter rotating layout closes that gap for the covered in-sandbox threat model. The question facing infrastructure providers is whether performance optimizations that share processes across tenants can ever fully eliminate side-channel risks, or whether the industry will eventually need to accept the latency cost of stricter boundaries. Trust in shared execution environments hinges on solving this tension without forcing customers to choose between speed and isolation.