Researchers have shared details about a remote Spectre information leak targeting Cloudflare Workers. In a production-like setup, a JSON Web Token (JWT) can be read out from the memory of a “victim” Worker. The researchers report a maximum exfiltration rate of 12 bits per second, which they say is much faster than an earlier demonstration from 2021.
Important: in the experiment, the JWT was deliberately placed into memory, and the researchers state that no customer data was accessed. Still, the topic raises a core question: how robust is memory isolation when multiple tenants share the same runtime and the same process?
What is the attack, and how does the Spectre information leak work?
The proof of concept revolves around two Workers: an attacker and a victim, both controlled by the researchers. The JWT was placed into the memory of the victim Worker. Next, the attacker Worker attempted to reconstruct information using a Spectre-like timing approach.
Cloudflare explains that Workers run code from multiple tenants in separate V8 isolates inside the same operating-system process. That means the separation relies largely on language and runtime isolation, not on strict process isolation.
According to Cloudflare, memory reads within the same Worker process can lead to cross-tenant leakage. The attack also requires that the attacker and victim Workers are co-located in separate V8 isolates within that single process.
Why it matters: co-location and process sharing
Cloudflare Workers is designed to start quickly and to run multiple environments efficiently. In the architecture discussed, this means: less overhead than full process isolation, but also dependence on the security measures around detection and in-process shielding.
The paper states that the production implementation of a defense mechanism intended to isolate suspicious scripts was not sufficient for this specific approach. That sets the tone for the discussion: not only “can it be done?”, but also “does the system detect it in time?”
Timing is the key: WebSocket and Durable Objects
A Spectre attack often hinges on exploiting subtle differences in execution time. In this research, the researchers mention WebSocket communication as a way to provide a remote timing source.
They also mention Durable Objects: this makes it possible to keep a Worker isolate alive long enough to repeat timing observations. The researchers describe that Durable Objects can keep a single Worker isolate running for five to more than 20 hours.
This matters because, in this scenario, the isolation defense only kicks in after an invocation. The researchers argue that a long-lived Durable Object invocation can continue before isolation takes place.
DyPrIs under pressure: detection versus suppression through I/O
Cloudflare uses Dynamic Process Isolation (DyPrIs) as a detection and defense layer. The mechanism is designed to isolate suspicious scripts in a separate process after an invocation.
According to the researchers, heavy WebSocket-driven input/output (I/O) can increase iTLB activity (instruction translation lookaside buffer). As a result, the normalized branch-misprediction signal strength that DyPrIs relies on drops. The outcome: the signal may fall below the detection threshold.
Cloudflare calls it a limitation in the DyPrIs implementation. The researchers counter that it is actually about fundamental limitations of the detection method, rather than a “misconfiguration” or an implementation bug.
How fast and how accurate was the leak?
The researchers report a leak of up to 12 bits per second with 99.16% accuracy. As a comparison, they note that the earlier 2021 attack is said to have been around 2 bits per minute.
They also indicate that higher system load reduces the leakage rate. At the same time, the researchers say that even under high load, it remains possible to run slower attacks.
For the measurements, Linux servers were used with AMD EPYC Zen 2 and Zen 3 processors. The tests were intentionally run at night, with CPU usage between 10% and 25%, to get closer to the “best” measurement conditions, according to the researchers.
What did Cloudflare do to mitigate the Spectre information leak?
Cloudflare states that the attack has already been mitigated in production. To support this, the company points to multiple improvements and hardening measures:
- Improved DyPrIs: Cloudflare says the detection capability of the isolation mechanism has been sharpened.
- V8 Sandbox: this should restrict access to 64-bit pointers.
- MPK-based in-process isolation: Worker heaps are placed behind hardware-enforced protection keys. Cloudflare says modern x64 systems still leave roughly 12 keys available for this purpose.
- Key combination and rotating memory layout: Cloudflare describes that the design combines the protection keys with the V8 Sandbox and uses a rotating memory layout to prevent nearby sandboxes from sharing the same key within the relevant threat model.
In an earlier publication (September 2025), Cloudflare describes that random MPK assignment on its own would “catch” about 92% of cross-isolate accesses, because two isolates could receive the same key. The stricter rotating layout should close the remaining gap for the protected in-sandbox threat model.
No sandbox escape, but a lesson about isolation
Cloudflare emphasizes that native code execution outside the threat model is not in scope, and that the attack does not depend on a V8 software vulnerability or a sandbox escape. That makes the case both interesting and frustrating: even without a “classic exploit,” information can still leak through subtle micro-architectural behavior and timing.
The company also states that Workers limit local timing sources by freezing or tightening timers during CPU execution. In addition, Worker scripts do not get shared memory or multithreading.
What can your organization do with this?
For organizations running on serverless platforms and managed runtimes, the takeaway is mainly: isolation is not a black-and-white concept. It’s not only about “can you run code?”, but also about “which signals are monitored?” and “which components enable timing?”
Practically, you can shift focus to:
- Risk assessment of co-location and which isolation layers the provider uses in production.
- Monitoring and patch policies for platform and runtime components (where possible through provider updates).
- Secure engineering: ensure sensitive secrets like JWTs don’t end up in contexts that increase risk for other processes or tenants.
If you want to go further on secure coding and DevSecOps principles, this event could be relevant: CodeSecCon: secure code & DevSecOps in one online event. For a broader view of attacks that rely on clever timing and environment, also read Phishing 3.0: from email scanning to agent-driven attack (context on how attackers are becoming more efficient in their approach).
Conclusion
The announced Spectre information leak shows that even with modern serverless runtimes, information can leak when conditions line up: co-location, a timing source, and a detection layer that just doesn’t have enough grip. The researchers report high exfiltration rates and strong accuracy in their controlled experiments.
Cloudflare says it has already mitigated the attack in production using improvements to DyPrIs, a V8 Sandbox approach, and MPK-based in-process isolation. For users, the key question remains: how well do you assess which parts of your environment are sensitive to “micro-architectural” leaks, so you can take targeted measures.
Source: https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html
