Cloudflare disclosed on August 19 that its own security researchers had pulled off a working Spectre-class attack against Cloudflare Workers, extracting a live JSON Web Token from a co-located Worker at up to 12 bits per second with better than 99% accuracy. The attack ran on Cloudflare’s real production infrastructure, not a lab simulation. Cloudflare says it was already mitigated before the writeup went public, through three separate isolation layers rolled out over the past year, and found no evidence it had ever been used in the wild.
How the attack actually worked
Spectre attacks exploit speculative execution, the trick modern CPUs use to guess ahead at what code will run next and roll back if they guessed wrong. The rollback is supposed to be invisible, but it leaves faint timing traces in the CPU cache. Researchers have known since 2018 that those traces can leak data across process boundaries if you can measure them precisely enough.
What made this version notable is how the researchers solved the “precisely enough” problem inside a serverless platform, where a Worker only gets to run for a short burst before Cloudflare tears it down. They used a type-confusion gadget to coax a Worker into reading a 64-bit pointer it shouldn’t have access to, amplified the resulting cache timing differences using a technique targeting the CPU’s PLRU cache replacement policy, and kept their own attack Worker alive far longer than normal by holding a WebSocket connection open through a Durable Object, resetting the runtime’s CPU limits along the way. That combination let them measure timing differences down to sub-millisecond precision and reconstruct a JWT byte by byte from a neighboring, unrelated Worker sharing the same process.
What Cloudflare already fixed
Cloudflare’s response predates the disclosure. Dynamic Process Isolation now flags long-lived, I/O-heavy executions as a security signal instead of only reacting after something suspicious happens. The V8 Sandbox strips raw 64-bit pointers out of large heap regions, which specifically breaks the type-confusion gadget this attack depended on. And Memory Protection Keys, deployed since September 2025, put each isolate’s heap behind a hardware-enforced boundary so even code running in the same process can’t reach across it. Cloudflare states plainly that the attack is already mitigated in production and that no customer action is required.
Why it’s still worth knowing about
Nobody running an app on Cloudflare Workers needs to change anything because of this specific research. But it’s a useful reminder for any team building APIs on shared, multi-tenant serverless infrastructure: process isolation from the platform vendor is one layer of defense, not the whole picture. Short-lived tokens with tight scopes limit the damage if a side channel like this one ever does get exploited before a vendor patches it, and it’s a reasonable thing to check for in any web application build that leans on JWTs for auth. Cloudflare’s full technical writeup and the companion research paper are worth a read if you want the underlying mechanics, not just the summary.
