The Cloud Is Still Shared Hardware: What Cloudflare's Spectre Reassessment Changes
Cloudflare's new Workers research leaked a JWT at up to 12 bits per second with more than 99% accuracy in production. The important lesson is not that edge isolation failed; it is that isola
TL;DR • Cloudflare says its updated proof of concept reliably leaked a JWT from a co-located Worker at up to 12 bits per second with more than 99% accuracy in production conditions.[1] • The attack depended on a chain of difficult primitives: co-location, a remote timer, speculative type confusion, cache-signal amplification, and long-lived execution through Durable Objects.[1] • The important lesson for platform buyers is not that serverless isolation is useless. It is that isolation claims must be continuously re-tested as runtimes, CPUs, and attack techniques change. The article covers What Cloudflare actually reassessed and Netics' take: isolation is a living contract.
What Cloudflare actually reassessed
Cloudflare Workers runs untrusted JavaScript from many tenants in the same operating-system process. V8 isolates give each Worker a separate JavaScript heap, while the shared process keeps startup latency low and improves density.[1]
The design is efficient, but it leaves a security question that no architecture diagram can permanently close: what happens if speculative execution lets one isolate observe traces from another? Spectre attacks do not require a normal JavaScript read primitive. They use transient CPU behaviour and cache timing to encode information indirectly.[1]
Cloudflare says it had already deployed Dynamic Process Isolation, or DyPrIs, after its earlier research. The new reassessment found a limitation in that defence and demonstrated a remote attack in the production environment. The researchers state that the tested attack was already mitigated by new production countermeasures and that they found no indicator of active exploitation over the preceding three years.[1]
The last point matters. This is a published defensive reassessment, not a claim that every Workers customer was compromised.
Why the attack was difficult but still relevant
The proof of concept needed several pieces to work together. The attacker had to place an attacker and victim Worker in the same process, find a usable remote timer, create a Spectre gadget, amplify a cache signal, and repeat noisy measurements until the bit classification became reliable.[1]
The researchers used a WebSocket-based remote timer and Durable Objects to keep an execution context alive. They combined cache-state preparation, branch mistraining, transient access, and repeated statistical measurement. In the reported production experiment, the result was leakage of up to 12 bits per second with more than 99% accuracy.[1]
This is not a copy-paste exploit recipe for an ordinary customer. It is a reminder that “the runtime prevents direct cross-tenant reads” is not the same as “the hardware cannot leak information across tenants.” Those are different claims and require different evidence.
Netics' take: isolation is a living contract
The usual cloud-security conversation treats isolation as a product property: a VM boundary, a process boundary, a language sandbox, or a provider statement. The Cloudflare paper shows why that is incomplete. Isolation is a living contract between the application runtime, the compiler and JIT, the CPU, the scheduler, the detection system, and the operational workload.
Cloudflare's own response illustrates the layered approach. It describes stronger V8 Sandbox protections, hardware-assisted in-process isolation using Memory Protection Keys, and improvements to DyPrIs. It also says the V8 Sandbox is not a complete Spectre mitigation and that Memory Protection Keys reduce the leakage surface without eliminating every risk.[1]
That is the right posture: reduce the attack surface, then keep testing the residual risk. Security language becomes dangerous when “mitigated” is interpreted as “solved forever.”
The operational detail is equally important. DyPrIs originally isolated suspicious scripts after an invocation finished. The research showed why that timing matters: a Durable Object and WebSocket-heavy Worker can keep a single invocation open for hours. A detection mechanism that acts only after completion can arrive after the sensitive work is done.[1]
For platform teams, long-lived and I/O-heavy workloads deserve their own threat model. They should not inherit the assumptions of short request/response functions simply because both are called “serverless.”
What this means for platform buyers
- Ask where tenant isolation actually lives. Is it a language heap, a process, a VM, hardware keys, or several layers together? Ask what each layer does not protect against.
- Ask how the provider tests the boundary. A compliance document is not a substitute for adversarial reassessment under production-like scheduling, noise, timers, and long-lived connections.
- Treat runtime changes as security changes. A JIT update, CPU migration, new scheduler behaviour, or new execution primitive can change the isolation argument without changing your application code.
- Separate “no known exploitation” from “no exploitable path.” Cloudflare reports no indicators of active exploitation in the period it reviewed. That is valuable evidence, but it is not a proof that the class of risk has disappeared.[1]
- Keep sensitive workloads compartmentalized. Provider isolation is one layer; application-level token scope, short-lived credentials, data minimization, and independent audit trails still matter.
Bottom line
Cloudflare's Spectre reassessment does not invalidate serverless computing. It does invalidate lazy language around isolation. Shared hardware remains shared hardware, even when the developer sees only a function and the provider supplies several layers of sandboxing.
The strongest takeaway is methodological: test the boundary again when the platform changes, when the workload becomes long-lived, and when researchers find a better way to turn microarchitectural noise into data. A secure platform is not one that claims the boundary is perfect. It is one that keeps looking for where the boundary can fail—and changes the runtime when it finds one.
Book a free 30-minute audit if your AI or serverless architecture depends on multi-tenant isolation and you want a threat-model review.
Original Netics diagram: shared serverless hardware means isolation must be retested.
Original Netics diagram: defense in depth reduces leakage but does not erase the shared-hardware boundary.
Source: A revisit of remote Spectre attacks on Cloudflare Workers — Cloudflare Blog, 2026-08-19.
Explore Netics for practical infrastructure and AI operations guidance.