Study reveals remote variant of Spectre that filters a JWT in Cloudflare Worker memory

Security researchers have published a controlled experiment that demonstrates a remote variant of Spectre capable of filtering a JSON Web Token (JWT) hosted in the memory of another Cloudflare Worker co- located within the same process, with a maximum exfiltration rate of up to 12 bits per second. In the end-to-end test, the authors executed an attacking worker and a "victim" worker under their control and deliberately placed the JWT in the second's memory to measure the channel. Cloudflare confirmed that the experiment did not access customer data and that it already deployed production mitigation; the company also stated that it did not find active operating indicators for the last three years.

Fact-finding: the technique is based on a version of the so-called "transit execution" or Spectre attacks, where speculative and microarchitectural readings become side channels of time to filter bits from another execution. In the surroundings of Cloudflare Workers this is only possible if the attacker and the victim end up co-located in different V8 isolates within the same process. The work of the researchers describes two key factors that facilitated the escape: first, that a remote timing channel was possible using WebSockets (the Workers do not expose local sources of high resolution timing); second, that the Durable Objects allow an island to remain active for hours, preventing the dynamic isolation policy (DyPrIs) from immediately relocating the code to a separate process.

Technically, the attack does not require the execution of native code or a V8 or "escape" vulnerability from the sandbox: the opponent executes legitimate code from his own isolate and exploits microarchitectural signals (such as iTLB states and branch predictors) to induce and measure observable effects through a remote connection. Researchers also documented that intensive I / O charges by WebSockets increase iTLB activity and reduce the detection signal used by DyPrIs - the Cloudflare heuristics to decide when to move a suspicious isolate to another process. According to the paper, this reduction in the signal allowed the detection to not fire while the leak occurred.

Confirmed by Cloudflare: Workers run multiple tenants in V8 isolates within the same process with the aim of reducing start latency, and their defense DyPrIs moves suspicious isolates to separate processes after an invocation. After disclosure, Cloudflare describes having expanded DyPrIs, integrated the "V8 Sandbox" (limited transitory access to 64-bit pointers) and deployed a process-based isolation scheme based on Memory Protection Keys (MPK) - a CPU feature that allows to protect memory regions with hardware keys - to reduce the possibility of cross-reading between isolates heaps.

Reproductive data from the study: the experiments were carried out on Linux servers with AMD EPIC Zen 2 and Zen 3 processors; to obtain the maximum exfiltration rate the authors worked on low-load windows (10-25% night CPU), and reported an accuracy of 99.16% in bit recovery at the maximum rate. The authors make it clear that with more system load the speed is decreasing, but the technique remains viable but slower. Historical comparison: the previous remote attack on Workers, published in 2021 by Cloudflare and TU Graz, reached about 120 bits per hour (~ 2 bits / minute); the new measurement represents a significant improvement in rate (up to about 360 times faster under controlled conditions).

What this means for users of Workers and cloud services: in practical terms, the technique shows that under certain conditions an actor with legitimate code deployed on the same platform can - theoretically - extract secrets stored in memory of other tenants. The test leaked a JWT, a type of secret that can allow API access or session validations if it is not bounded in time. Although the ability to exfilter tens of bits per second still involves a relatively slow process to obtain long secrets, automation and repetition allow for reconstructing keys or tokens over time.

What is confirmed and what remains uncertain: it is confirmed that the technique works in laboratory against the pre-patch production configuration, and that Cloudflare has deployed mitigation. It is not confirmed that there has been exploitation in real customers; Cloudflare reports no indicators in the last three years. It is uncertain to what extent the mitigations (improved DyPrIs combination, V8 Sandbox and MPK) eliminate all the practical exploitation in all scenarios and architectures, and how much performance or compatibility impact they will have on scale.

Possible real consequences: for loads that keep long Workers in memory (e.g. Durable Objects with long invocation) or that use intensive WebSockets, there is a higher risk of exploitable co-location. Long-term secrets saved in Workers' memory (API keys, JWT with comprehensive TTL, global variable credentials) are the most vulnerable assets. For multi-tenant environments where co-location is common, this type of channel highlights the tension between latency optimization and process purist insulation.

Specific recommendations for developers and administrators: First, treat secrets as short-term: reduce tokens TTL, often critical key rote and apply scope limits. Avoid keeping sensitive secrets in global variables in Workers; use bindings of managed secrets and external services with additional checks (e.g. OAuth with controlled refresh). For architectures that use Durable Objects or WebSocket connections, consider narrowing the life time of long invocation or fragmenting state to minimize surfaces in memory. Activate and review your supplier's policies and login to detect co- unusual locations or long WebSocket patterns. If you handle very sensitive data, evaluate to require execution in process-isolated environments or dedicated instances.

Recommendations for platform operators: implement real-time detection during execution (not only post-invocation), and use signals that cannot be easily dampened by I / O activity Combining hardware protections like MPK with V8 sandboxing and rotary memory layouts reduces the likelihood that two isolates share the same protection key, but these measures should be evaluated against real loads and multiple CPU architectures. Maintain proactive audits and searches of remote timing patterns using WebSockets as a channel and limit the exposure of persistent connections when not necessary.

Sources and additional reading: original technical explanation of Spectre https: / / spectreattack.com / spectre.pdf, and the documentation of Cloudflare Workers to understand the operating model of isolates and Durable Objects https: / / developed. For details on Memory Protection Keys in CPU x86, see the Intel guide on MPK https: / / www.intel.com / content / www / us / en / developed / articles / technical / memory-protection-keys.html.

In short, the research reopens the discussion on the safety of offering language-level isolation (V8 isolates) within the same process to optimize latency. The mitigations deployed by Cloudflare reduce the attack surface, but the shared responsibility also lies with developers and operators: to minimize secret life times, to avoid long operating patterns in memory and to audit intensive use of WebSockets are practical steps that limit exposure while continuing to assess the effectiveness of the protections on a scale.