A co-located tenant's JWT was shown to be extractable from Cloudflare Workers via Spectre

TL;DR

Cloudflare disclosed that it reassessed and demonstrated a remote Spectre attack on Workers — a serverless environment where many tenants share one OS process — that could extract a co-located tenant’s JWT under production-like conditions. At up to 12 bits/second with over 99% accuracy, it read from another tenant’s memory through a speculative-execution side channel. A JWT is treated such that merely holding it is proof of being “a logged-in user.” What was missing was a layer to verify that whoever presents the token is its legitimate holder.

What happened

• The Cloudflare Workers Runtime team, with academic researchers (including Haocheng Xiao of the University of Edinburgh), reassessed the remote Spectre attack on Workers first evaluated in 2021. It published a paper (arXiv:2608.17043); the research was carried out in 2024 and early 2025.
• In production, it demonstrated reading another tenant’s memory at up to 12 bits/second with 99% accuracy. Workers co-locates tens of thousands of tenants in one process via V8 isolates; each Worker has its own heap, but a single arbitrary read can lead to cross-tenant leakage.
• Using Durable Objects — built for real-time coordination — the attacker held one isolate alive with WebSocket keep-alives, repeatedly resetting CPU-time and request limits and securing the persistent timing channel the attack needs. This evaded DyPrIs, which isolates malicious-looking scripts only after execution.
• Cloudflare writes that it placed a JWT in the victim Worker and leaked it bitwise. A JWT is the credential many web apps use to prove a user is logged in; stealing it silently means stealing that session.

The chain:

1. An attacker Worker co-locates in the same process as a victim Worker.
2. Durable Objects and WebSockets keep one isolate alive, providing a persistent timing channel.
3. A Spectre side channel reads the neighboring tenant’s memory (including a JWT) one bit at a time.
4. Presenting the JWT passes as that session’s user, with no check on whether the presenter is the legitimate holder.

Timeline — disclosure and response

• 2024–early 2025: Cloudflare Workers Runtime team conducts the production reassessment.
• 2025-09: deploys in-process isolation using Memory Protection Keys (MPK).
• 2026-08 (disclosure): Cloudflare publishes the paper and write-up, demonstrating leakage at 12 bits/second with 99% accuracy in production. The attack was already mitigated in production at disclosure (improved DyPrIs, integrated V8 Sandbox, MPK), and Cloudflare states it found no indicators of active exploitation over the past three years.

This Brief concerns a platform’s own production demonstration, not real-world harm. The attack was mitigated at disclosure, with no indicators of active exploitation. The figures (12 bits/second, over 99%), the mitigations, and the JWT-extraction experiment all follow Cloudflare’s own disclosure.

Points and response:

• The platform mitigated a hard-to-close side-channel path by layering isolation and detection. That is an important defense, but its premise is not that “a stolen credential won’t pass on the thief’s side.”
• A bearer token like a JWT is treated as identity by mere possession, so once leaked, the holder can no longer be distinguished.

Why it wasn’t stopped

The focus here is not only the difficulty of closing a side channel like Spectre. There is no layer that verifies whether whoever presents a stolen JWT is its legitimate holder.

A JWT is treated such that holding it is itself proof of being “a logged-in user” (a bearer token). So if a co-located tenant reads it silently via a side channel, the thief can act in that session, indistinguishable from the legitimate user. DyPrIs, which isolates malicious-looking behavior, functions as a defense but was evaded by a persistent connection. What was missing was the step before: verifying that the one presenting this token is really its holder.

A bearer credential passes as identity by possession. The moment a token leaks, the distinction between the holder and the thief disappears. Identity is secured not by holding a token, but by a proof that can be shown without sending the key.

This runs in the same direction as Brief 006, where a credential stayed valid after revocation, and Brief 075, where an unrevoked old credential and a long-lived OAuth token became an intrusion path. In each, a credential’s possession is not bound to being its legitimate holder.

What proof would have changed

Proof-as-auth replaces session authentication built on a replayable bearer token with a proof of identity that never sends the key. It does not try to keep the token from leaking (side channels are hard to close). It keeps a leaked token from passing as the user.

The design Lemma offers against this gap:

• Identity proof without sending the key: base session auth not on a secret that passes by possession (a bearer token), but on a proof only the legitimate holder can show without sending the key itself.
• Verifying the presenter's legitimacy: make it possible for the receiving side to verify, before authorizing an action, that the one presenting the credential is its legitimate holder — not treating possession as identity.
• Scope and short life: pin the authority a session can demonstrate to what is needed, narrowing the replay window if it leaks.

What it does not do:

• Closing a side channel like Spectre itself is the job of runtime and CPU isolation and mitigation. This layer sits after that, keeping a leaked token from passing as the user.
• Proof can show only that a presenter is the legitimate holder — not protect against a user's own endpoint being compromised by another path.
• Which sessions get this authentication is the operator's decision; this layer supplies the means, not the decision.

The difference from your own access logs is here: a log remains after the token is used, but it is not material for distinguishing, before the action, whether the presenter was the legitimate holder.

Detection and this layer are complementary, not substitutes. The former catches malicious-looking behavior and lowers the probability of leakage; the latter keeps a leaked token from passing straight through as the user.

Sources

• Cloudflare (primary, official): “A revisit of remote Spectre attacks on Workers” (2026-08) — https://blog.cloudflare.com/revisiting-spectre-attacks-on-workers/
• arXiv (primary, paper): Pedersen, Xiao, Ainsworth, Topham, Schwarzl, “Remote Spectre attacks on Cloudflare Workers” (arXiv:2608.17043) — https://arxiv.org/pdf/2608.17043
• The Hacker News (independent): “Cloudflare Workers Spectre Attack Leaks JWT From Co-Located Worker at 12 Bits/Second” (2026-08) — https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html

This document is a structural analysis of public information, not an audit, assessment, or recommendation regarding any specific organization. The attack was mitigated in production as of disclosure.