Academic researchers found a way to pull secret data out of a Cloudflare Worker's memory from another, unrelated Worker running on the same physical server, without breaking out of any sandbox or running native code. The team, based at TU Graz, used a Spectre-style timing side channel to recover a JSON Web Token (JWT) they had planted in a victim Worker, extracting it at up to 12 bits per second with 99.16 percent accuracy. Cloudflare confirmed the research and has already shipped fixes.
For context, Spectre is a class of hardware vulnerability discovered in 2018 that lets code infer secret data by measuring how long certain operations take, exploiting speculative execution inside a processor. A previous demonstration against Cloudflare Workers, published in 2021, managed roughly 2 bits per minute. The new result is about 360 times faster, a figure that holds up: 12 bits per second works out to 43,200 bits per hour, versus roughly 120 bits per hour for the 2021 attack.
How the attack actually works
Cloudflare Workers run as lightweight V8 isolates rather than full virtual machines, which is what makes the platform fast to cold-start. For efficiency, isolates belonging to different customers can share the same operating system (OS) process. That co-location is normally invisible to tenants, but it also means their code shares the same physical central processing unit (CPU) core and cache hardware at various points.
The researchers' attacker Worker and a victim Worker holding a JWT were placed in the same process. By repeatedly measuring how long certain memory accesses took, the attacker could infer bits of the token's contents one at a time, the classic Spectre pattern applied to this shared-process setup. No V8 exploit, no sandbox escape, and no native code were needed; the side channel alone was enough.
Why it took hours, not seconds
Cloudflare already has a defense for exactly this scenario: Dynamic Process Isolation (DyPrIs), which watches hardware performance counters for signs of speculative-execution abuse, such as an unusual rate of branch mispredictions, and moves a suspicious Worker into its own isolated process. Under normal conditions, DyPrIs should shut this kind of attack down quickly.
The researchers found a gap in how DyPrIs scores that signal. It normalizes the branch-misprediction count against instruction Translation Lookaside Buffer (iTLB) accesses, a separate CPU counter tied to instruction-fetch activity. Generating heavy WebSocket traffic inflated iTLB activity, which diluted the ratio and kept the attack under DyPrIs's detection threshold.
The other piece was time. Cloudflare's Durable Objects, a feature for stateful, single-instance Workers, can keep one Worker invocation alive far longer than a typical request. By sending periodic WebSocket keep-alive pings, the researchers kept a single invocation running for hours, with invocations reportedly lasting anywhere from about five to more than twenty hours in testing, enough time to complete the slow, bit-by-bit leak before isolation would otherwise kick in.
What Cloudflare has changed
Cloudflare says it deployed fixes for this class of issue starting around September 2025, before the research was published. Three changes stand out:
- Hardened DyPrIs so it correctly flags long-lived, I/O-heavy Workers instead of letting sustained WebSocket traffic mask the misprediction signal.
- Integrated the V8 Sandbox, a V8 engine feature that strips raw 64-bit pointers out of heap data structures, making it harder for a timing leak to resolve into a usable memory address even if a side channel exists.
- Added Memory Protection Keys (MPK)-based isolation, a hardware feature that lets the OS enforce separate memory access permissions for different isolates sharing one process, adding a hard boundary inside a process rather than relying solely on process-level separation.
No evidence of real-world exploitation
Cloudflare says it reviewed roughly three years of activity and found no indicators that this technique, or the 2021 predecessor, was ever used against real customers. The JWT extracted in the demonstration was planted by the researchers themselves in a Worker they controlled; no customer data was accessed during the research. This is a disclosed and now-patched research finding, not a reported breach.
What this means for developers building on edge and serverless platforms
The underlying lesson is not specific to Cloudflare. Any platform that packs multiple tenants' code into a shared process for speed, whether that is an edge runtime, a serverless function host, or a multi-tenant sandbox, has to balance startup performance against this kind of cross-tenant leakage risk. Isolate-based architectures are efficient precisely because they share more than a full virtual machine would, and that sharing is what a side channel like this exploits.
Practically, there is little for individual developers to do here directly since the fix lives in the platform, not in application code. But it is a reminder not to treat co-located isolates as a strong security boundary on their own. Avoid keeping long-lived secrets, such as signing keys or long-lived tokens, resident in memory for extended periods inside a single Worker invocation when short-lived tokens or per-request secrets are an option. If your workload relies on long-running Durable Object connections kept open with keep-alive traffic, expect that pattern to draw more scrutiny from isolation policies going forward. Most importantly, keep an eye on your provider's security advisories, since this kind of hardware side-channel research tends to resurface against new platforms as speculative-execution defenses evolve.
