Back to Tech Radar
securityAug 28, 2026

Cloudflare's Spectre Test Exposed a Blind Spot in Invocation-Bound Detection

Cloudflare recreated a remote Spectre attack in its Workers production environment against attacker and victim Workers controlled by the researchers, leaking an intentionally placed secret at up to 12 bit/s with more than 99% accuracy under the controlled test conditions. The test exposed two limits in Dynamic Process Isolation: DyPrIs could move a script it flagged into a separate process only after the current invocation finished, while I/O-heavy WebSocket timing traffic diluted its normalized detection signal. Cloudflare says the demonstrated attack is already mitigated and no customer data was accessed. The broader builder inference is that security controls for shared-process runtimes must account for workload lifetime and I/O behavior.

Abstract 3D serverless infrastructure with a spectral figure, timing wave, and layered security shields protecting connected compute nodes.

Summary

Cloudflare recreated a remote Spectre attack in its Workers production environment against attacker and victim Workers controlled by the researchers, leaking an intentionally placed secret at up to 12 bit/s with more than 99% accuracy under the controlled test conditions. The test exposed two limits in Dynamic Process Isolation: DyPrIs could move a script it flagged into a separate process only after the current invocation finished, while I/O-heavy WebSocket timing traffic diluted its normalized detection signal.

Cloudflare says the demonstrated attack is already mitigated and no customer data was accessed. The broader builder inference is that security controls for shared-process runtimes must account for workload lifetime and I/O behavior.

Key Updates

Research scope: The research was conducted in 2024 and early 2025, then disclosed on August 19, 2026. The end-to-end test used attacker and victim Workers controlled by the researchers, with an intentionally placed JWT in the victim. No customer data was accessed.

Long-lived execution: Durable Objects provided a long-lived context. By yielding between WebSocket keep-alives, the researchers kept an isolate alive for five to more than 20 hours. In the attack, a long-running invocation let the leak complete before DyPrIs could apply post-invocation isolation.

Detection-ratio dilution: The WebSocket-based remote timer created a large I/O loop. That traffic increased iTLB accesses; because DyPrIs normalized branch mispredictions by the number of iTLB accesses, the ratio fell below its detection threshold.

Detection changes: Cloudflare improved DyPrIs so long-lived executions and I/O-heavy workloads are handled as first-class security cases. It is also investigating remote timing behavior as an additional detection signal.

Layered mitigation: The V8 Sandbox blocks the specific 64-bit leak gadget used in the test, while Memory Protection Keys, deployed for per-heap isolation in September 2025, block the straightforward cross-isolate read on which it relied. Cloudflare says neither is a complete Spectre mitigation. The company says the demonstrated attack is mitigated and reports no indicators of active exploitation over the previous three years.

Why It Matters

The important signal is not that Spectre has been solved, or that Cloudflare Workers suffered a customer breach. Neither claim is supported.

Cloudflare's shared-process model gains speed and density by placing many isolated tenants inside one operating-system process. It depends on overlapping controls: language-level isolation, runtime hardening, behavioral detection, process isolation, and hardware-enforced memory boundaries. The broader lesson for shared-process, multi-tenant runtimes is that no single layer should carry the full isolation burden.

Stateful serverless features can change the assumptions behind detection. Durable Objects and WebSockets are legitimate building blocks, not inherently unsafe features. In this controlled test, their long-lived and I/O-heavy behavior exposed a mismatch between workload lifecycle and a detector whose response waited for invocation completion. A workload-influenced normalization ratio created a second blind spot.

A detector that could apply isolation only after invocation completion was insufficient against this controlled attack.

Builder Takeaway

Runtime and platform teams should inventory long-lived execution modes, test persistent channels and adversarial I/O, ensure long-running work cannot defer a security response until too late, test normalized signals for denominator dilution, and add hardware-enforced memory boundaries where applicable.

Application builders cannot patch speculative-execution behavior from application code, and the source gives them no emergency remediation step. Their task is to understand the provider boundary: whether sensitive workloads share processes, which hardware-backed isolation exists, how long-lived or streaming execution is monitored, and what residual side-channel risk the provider acknowledges.

How strong is this signal for builders?

Signal feedback is stored anonymously and used to improve Tech Radar editorial quality.

Want more operational technology signals?

Follow uniQubit Tech Radar or contact uniQubit about a product, partnership, or operational software need.

Sources