Cloudflare Workers Spectre attack leaked a JWT at 12 bit/s: the 2026 DyPrIs failure

Summary. On 19 August 2026 Cloudflare published a remote Spectre attack that leaked a JWT from a co-located Worker in its own production environment at up to 12 bit/s with more than 99% accuracy. The academic paper behind it, submitted to arXiv on 17 August 2026, puts the accuracy at 99.16% and describes the previous state of the art as 2 bit/min. That earlier figure comes from Cloudflare's own 2021 work, which measured 120 bit/h and shipped Dynamic Process Isolation (DyPrIs) as the fix. The 2021 paper claimed a 0.61% false-positive rate and said DyPrIs "statistically provides the same security guarantees as strict process isolation". Five years later, an author of that paper helped break it. Cloudflare says the attack is already mitigated in production through an improved DyPrIs, the V8 Sandbox and Memory Protection Keys deployed in the 25 September 2025 hardening work, and that it found no indicators of active exploitation over the last three years. There is no CVE, and Cloudflare asks customers on the $5/month Workers Paid plan to do nothing.

That last sentence is where the two documents stop agreeing.

The vendor and the paper describe different severities

Cloudflare's post, written by Martin Schwarzl and Albert Pedersen of Cloudflare, opens with a careful noun phrase: "Our research uncovered a limitation in the implementation of DyPrIs". The wording puts the fault in the implementation, not the design.

The arXiv abstract for "Remote-Timer-as-a-Service: Efficient Microarchitectural Leakage in the Cloud with Remote Timers" is blunter. It says "the production implementation of DyPrIs was insufficient", then goes further: "we show that freezing and coarsening timers in the Cloudflare Workers security model is insufficient". The first clause is about a build. The second is about the model Kenton Varda described on the Cloudflare blog on 29 July 2020, in which Date.now() has been frozen for the duration of an invocation since mid-2017 and multi-threading and shared memory are absent so a tenant cannot construct an implicit clock.

The paper also states the attack was "posing an immediate risk to customer data". The blog states no customer action. Both are defensible: the risk was real when the research ran in 2024 and early 2025, and the mitigations shipped before publication. But a reader who only sees the blog will conclude the timer model held and one detector had a bug. The paper says the timer model did not hold, because the timer no longer has to be local.

How the leak was actually built

The chain matters more than the headline rate, because three of its five links are ordinary platform features.

Co-location came first, and it is the part that should worry anyone running untrusted code beside their own. Cloudflare writes that "invoking the victim script from the attacker script with a fetch("https://victim.example") will in most cases cause the scheduler to spin up an instance of the victim worker in the exact same process", and confirms machine placement by reading the fl value from the /cdn-cgi/trace endpoint. Cloudflare's own summary of the difficulty: "One might intuitively think this would be difficult, considering Cloudflare operates tens of thousands of edge servers, but this is in fact quite trivial on Cloudflare Workers."

The timer came second. Local high-resolution clocks are gone, so the researchers put the clock on the network: a WebSocket connection to an external server serving timestamps, with the Worker asking for a mark before and after an event. They report sub-millisecond resolution on the median with a handful of samples, even across topological distance.

Amplification came third, and it is borrowed. Stephen Röttger and Artur Janc of Google published the Tree-PLRU technique on the Google Security Blog on 12 March 2021, demonstrating 1 kB/s on Chrome 88 on an Intel Skylake CPU and 60 B/s with timers of 1 ms precision or worse. Their insight was that abusing tree-based pseudo-least-recently-used cache replacement amplifies the timing signal from a single read of secret data. Cloudflare applied the same idea, so a nanosecond-scale cache event survives a millisecond-scale clock.

Eviction was solved by refusing to do it. Rather than build an eviction set with a noisy timer, the attack allocates a pool larger than the last-level cache and picks a fresh random pair each round. For a 256 KB L2 cache, allocating 64 MB leaves at most a 1-in-256 chance that a given line is still resident.

Persistence came last, from Durable Objects. The runtime treats every incoming WebSocket message as an invocation that resets the CPU time and request limits, and an isolate is single-threaded, so keep-alives are only processed when the script yields. Yielding between compute bursts kept an isolate alive "from five to more than 20 hours". At the time of the research the limits were 30 seconds of CPU time and 1,000 subrequests per invocation.

With all five in place the order of extraction was: the isolate root address, then the vDSO region as a sanity check because it contains readable strings such as gettimeofday, then a JWT the researchers had planted in a victim Worker they controlled. The first byte was e, 0b01100101.

Why the detector did not fire

Cloudflare gives two reasons, and both are structural rather than accidental.

"Detection cannot happen only after a script finishes. A Durable Object or a WebSocket-heavy Worker can run long enough that post-execution isolation arrives too late." DyPrIs isolates a script after its invocation ends. The keep-alive trick keeps one invocation open for hours, so the leak completes first.

The second reason is subtler. DyPrIs normalises branch mispredictions by the number of iTLB accesses. The remote timer is one large I/O loop, and that WebSocket traffic inflates iTLB activity, so, in Cloudflare's words, "the normalized ratio drops below the detection threshold, so the attack looks like an ordinary I/O-heavy Worker". The evasion is not noise. The signal the detector uses to suppress false positives is generated by the attack itself.

Cloudflare's fix is to treat long-lived executions and I/O-heavy workloads as first-class security cases, and it says it is "currently investigating" whether remote timing behaviour could become an extra dimension of DyPrIs. That second item has not shipped.

The keep-alive primitive is still documented

This is the part a platform team can act on. The mitigations are Cloudflare's to deploy, but the resource behaviour that gave the attack a 20-hour window is still current documented behaviour, and it has the same effect on your own runaway or hostile code.

The Durable Objects limits page, last updated 1 June 2026, states it plainly: "Each incoming HTTP request or WebSocket message resets the remaining available CPU time to 30 seconds." The Workers limits page, last updated 28 July 2026, shows wall time for an incoming HTTP request and for Durable Objects RPC/HTTP as Unlimited, subrequests at 10,000 per invocation on the Paid plan, and CPU time raisable from the 30-second default to 5 minutes with cpu_ms: 300000. Cloudflare's pricing page, last updated 7 July 2026, bills CPU time at $0.02 per additional million CPU milliseconds above 30 million included per month.

If you run Durable Objects behind WebSockets, that table is also your bill. A session that never ends is a session you never see terminate in metrics. Our engineering read is unchanged from the last time we looked at Cloudflare Workers and Vercel Functions cost: the interesting number in an edge platform is rarely the request price, it is what the platform lets a single invocation hold open.

What actually stands between tenants now

Three mitigations, and Cloudflare hedges two of them itself.

Improved DyPrIs closes the two blind spots above. The V8 Sandbox limits transient access to 64-bit pointers, which kills the specific gadget used here: under pointer compression most V8 objects use 32-bit compressed pointers, and TypedArray was one of the few exceptions still storing a raw 64-bit pointer to its backing store. Cloudflare's caveat is direct: "The V8 sandbox is not a complete Spectre mitigation. While the presented 64-bit leak gadget does not work anymore, there might be other Spectre variants or gadgets exploitable to achieve arbitrary out-of-bounds memory accesses."

Memory Protection Keys came from the 25 September 2025 hardening post by Erik Corry and Ketan Gupta. Each isolate gets a key protecting its V8 heap data. Their arithmetic: "There are up to 15 different keys available on a modern x64 CPU and a few are used for other purposes in V8, so we have about 12 to work with", which makes a cross-isolate read hit a hardware trap "in 92% of cases". The remaining 8% closes only in a specific arrangement, where keys are assigned by strict rotation so that no sandbox within 32 GiB shares a key. Cloudflare's own limit statement: "MPK is not a complete answer to remediate Spectre, but it strictly reduces the leakage surface." MPK also assumes the attacker cannot execute arbitrary machine code, because that would let them disable protection keys outright.

Varda's 2020 framing has aged well: "A dirty secret that the industry doesn't like to admit: no one has 'fixed' Spectre. Not even when using heavyweight virtual machines. Everyone is still vulnerable." What changed in 2026 is the cost of the attack, not its possibility.

Who this affects, and how to tell if that is you

You are directly exposed only if a third party runs code inside your process boundary. Three groups qualify.

Anyone building on Workers for Platforms, where customer scripts share your account's runtime. Anyone running user-supplied JavaScript in a shared V8 host, including agent sandboxes that execute model-generated code. And anyone whose threat model assumed language-level isolation was equivalent to process isolation because a 2021 paper said so.

If none of that is you, the honest answer is that this changes nothing operationally on Cloudflare. The mitigations are deployed, the isolation boundary is the provider's to defend, and there is no patch on your side. What it should change is a design assumption: a sandbox that cannot be escaped in software can still be read through the hardware, and "we removed the timer" is not a durable defence once the tenant can open a socket. That reasoning belongs in the same review as your multicloud security posture and CSPM work, because tenancy boundaries are exactly the control that cloud posture tooling reports on but rarely tests. The same gap shows up when teams compare AWS Security Hub and Azure for multicloud CSPM: the tools grade configuration, not co-tenancy.

Practical checks, in order:

1. Inventory every place third-party or model-generated code executes in a process you also use for secrets. Agent tooling is the fastest-growing instance of this.

1. Stop treating a shared-process sandbox as a secret boundary. Secrets that a co-tenant could read given an arbitrary-read primitive belong behind a network call, not in the same heap.

1. Rotate anything long-lived that sat in a Worker heap. A JWT is exactly what was demonstrated; short expiry is the cheapest control you own.

1. Alarm on Durable Object sessions that hold an isolate open for hours. The behaviour is legitimate, which is the point, and the same pattern shows up in Durable Objects production work with the Cloudflare Agents SDK.

What is still unknown

Cloudflare does not say how it determined that no exploitation occurred over three years, nor what telemetry or retention period supports that statement. It gives no CPU model for the tests, so the 256 KB L2 figure and the Tree-PLRU assumption are the only hardware detail on the record from the blog. It gives no deployment date for the V8 Sandbox and no percentage of the fleet running MPK, and it notes that not all hardware in the fleet had been upgraded as of September 2025. The remote-timing dimension of DyPrIs is still described as under investigation. None of that is unusual for a coordinated disclosure, but none of it should be filled in from a summary article either.

FAQ

How eCorpIT can help

eCorpIT designs and reviews multi-tenant architectures on edge and serverless platforms, including the boundary questions this research makes concrete: where untrusted code runs, what shares a process with a secret, and how long a session may hold a runtime open. We are ISO 27001:2022 certified and CMMI Level 5 appraised, and our senior engineering teams run architecture reviews aligned with the tenancy-isolation requirements your customers audit you against. Talk to us via /contact-us/ if you run customer code beside your own.

References

1. A revisit of remote Spectre attacks on Cloudflare Workers — Cloudflare, 19 August 2026.

1. Remote-Timer-as-a-Service: Efficient Microarchitectural Leakage in the Cloud with Remote Timers — arXiv, submitted 17 August 2026.

1. Dynamic Process Isolation — arXiv, submitted 10 October 2021.

1. Spectre research with TU Graz — Cloudflare, 12 October 2021.

1. Mitigating Spectre and other security threats: the Cloudflare Workers security model — Cloudflare, 29 July 2020.

1. Safe in the sandbox: security hardening for Cloudflare Workers — Cloudflare, 25 September 2025.

1. A Spectre proof-of-concept for a Spectre-proof web — Google Security Blog, 12 March 2021.

1. Cloudflare Workers limits — Cloudflare Docs, last updated 28 July 2026.

1. Durable Objects limits — Cloudflare Docs, last updated 1 June 2026.

1. How Workers works — Cloudflare Docs, last updated 23 April 2026.

1. Cloudflare Workers pricing — Cloudflare Docs, last updated 7 July 2026.

Last updated: 20 August 2026.