Researchers working with Cloudflare demonstrated a remote Spectre attack that crossed the boundary between two co-located Cloudflare Workers isolates in the company’s production environment. The controlled proof of concept recovered a deliberately placed JSON Web Token from a victim Worker.
The original research paper reports leakage of up to 12 bits per second with approximately 99% accuracy. Cloudflare says the disclosed attack is already mitigated in production and that it found no indicators of active exploitation during its review of the previous three years.
Those findings do not mean customer data is currently exposed. The researchers controlled the attacker and victim Workers used in the experiment, and the paper says no customer data was accessed. Cloudflare also did not announce a customer-side patch, configuration change, or emergency credential-rotation requirement.
What the Production Test Proved
Cloudflare said the research took place during 2024 and early 2025, although the paper and company disclosure were not published until August 2026. The publication date therefore should not be interpreted as the start of a newly discovered active attack.
The production setting makes the result significant. The researchers tested their proof of concept while the platform’s existing runtime restrictions and detection systems were active. They recovered a test JWT from the memory of a controlled victim Worker running alongside the attacker Worker.
An earlier Workers Spectre experiment achieved a reported leakage rate of about two bits per minute. The new paper reports a maximum of 12 bits per second, making its peak result 360 times faster.

That improvement showed that removing local high-resolution timers, shared memory, and multithreading did not make remote timing attacks impractical. It did not demonstrate that an outside attacker stole a real customer token.
Why the Existing Workers Defenses Were Bypassed
Cloudflare Workers runs code from many tenants inside separate V8 isolates that can share one operating-system process. Each isolate receives its own JavaScript heap, but the design avoids assigning a complete process or virtual machine to every workload. This reduces startup time and allows the platform to run more workloads efficiently.
The same performance trade-off appears in Cloudflare’s isolate-based shared runtime for AI agents, where lightweight tasks can use isolates while heavier work is sent to containers.
Spectre exploits traces left in a processor’s microarchitectural state after speculative execution. Although the processor discards an incorrect speculative result, changes left in its cache can reveal information through carefully measured timing differences.
Workers restricted the local timing tools commonly used for this type of attack. The new research showed that the small timing difference produced by a cache event could be amplified enough to measure through a remote timing source. The researchers also demonstrated co-location, placing their controlled attacker and victim Workers inside the same process required for the cross-isolate leak.

Cloudflare’s Dynamic Process Isolation system, known as DyPrIs, was designed to recognize suspicious performance-counter activity and move a potentially malicious Worker into a separate process. According to the researchers, isolation occurred after an invocation ended. A sufficiently long-running workload could therefore continue before the isolation decision took effect.
The remote-timing traffic also made the workload resemble ordinary I/O-heavy activity. That weakened the normalized performance signal DyPrIs used to identify a possible Spectre attack.
How Cloudflare Changed the Workers Security Model
Cloudflare’s technical disclosure says the company integrated the V8 Sandbox into Workers. The sandbox removes the raw 64-bit pointer structure used by the demonstrated attack and limits where a memory-access primitive can reach. Cloudflare cautions that this makes the disclosed technique harder to reproduce but does not eliminate every possible Spectre variant.
In September 2025, Cloudflare also deployed in-process isolation based on Memory Protection Keys, or MPK. This hardware feature places tenant heaps into separate protection domains within the shared process. An isolate attempting to access a heap protected by another key can be blocked by the processor. This adds a hardware-enforced boundary without requiring Cloudflare to place every Worker in a separate process.

Cloudflare also changed DyPrIs so that long-running executions and I/O-heavy workloads receive additional attention. Detection can no longer depend only on evaluating a script after it finishes. The company says it is investigating whether repeated remote-timing behavior can become another signal for identifying suspicious workloads.
The defenses address different parts of the attack. The V8 Sandbox restricts the memory primitive used in the experiment, MPK adds a hardware boundary around tenant heaps, and DyPrIs monitors runtime behavior. Cloudflare describes their combined deployment as the mitigation for the demonstrated attack chain.
What Workers Customers Need to Know
Cloudflare did not announce a patch that Workers customers must install or a configuration they must enable. Its disclosure presents the mitigation as a platform-side change already deployed in production.
Cloudflare describes the mitigation as a platform-side production change rather than a customer-side rollout, and Cloudflare did not describe separate mitigation stages for different countries or regions.
The disclosure alone does not provide evidence that customers should assume their tokens were compromised. Organizations that have independent signs of credential misuse should follow their normal incident-response process, including reviewing token activity and rotating affected secrets.
Worker applications should continue using short-lived and narrowly scoped credentials where possible. That limits the potential impact of a leaked credential regardless of the technique used to obtain it.
What Remains Unknown
No independent team has publicly reproduced the complete production attack result located during this review. The paper provides detailed experimental evidence, but some of its authors are affiliated with Cloudflare, and the current mitigation status comes from the company.
Cloudflare says it found no indicators of active exploitation over the previous three years. Its public disclosure does not describe every log source, retention limit, or detection constraint behind that review. No indicators found should therefore not be rewritten as proof that exploitation was impossible.
Cloudflare also acknowledges that neither the V8 Sandbox nor MPK eliminates every theoretical Spectre risk on its own. The next useful evidence would be an independent reproduction, more detail about the exploitation review, or further information about remote-timing detection in DyPrIs.