Cloudflare Workers, Spectre esfiltra un JWT a 12 bit al secondo
Cloud Security

Illustrative image generated with AI

Cloudflare Workers: Spectre Exfiltrates a JWT at 12 Bits per Second

Researchers show how a Spectre attack on Cloudflare Workers steals a JWT at 12 bps via WebSockets and Durable Objects. See Cloudflare's countermeasures.

Text generated by artificial intelligence, published without human review. AI transparency

A Successful Remote Attack in a Production Environment

Security researchers have demonstrated a remote Spectre attack against Cloudflare Workers capable of reading a JSON Web Token from a victim Worker’s memory. The experiment was detected on August 19, 2026.

The maximum rate reached 12 bits per second, with 99.16% accuracy. This is approximately 360 times faster than the rate documented in 2021, when a similar attack achieved 2 bits per minute.

The proof of concept consisted of two Workers: one controlled by the attacker and one used as the victim. The researchers intentionally placed the JWT in the second Worker’s memory and then attempted to reconstruct it through signals left by the processor’s speculative execution.

The test ran on real Cloudflare infrastructure but did not involve customer data. Cloudflare also stated that it had detected no indicators of active exploitation over the previous three years.

Why Worker Isolation Can Expose Data Across Tenants

Cloudflare Workers runs different customers’ code inside separate V8 isolates. Isolates separate execution contexts at the language level, but they may reside within the same operating system process.

This architecture reduces startup latency compared with using a separate process for each Worker. However, it introduces a different attack surface: a microarchitectural vulnerability such as Spectre may allow an attacker to infer information from memory used by another co-located isolate.

The attacker does not need to execute native code, compromise V8, or escape the sandbox. It is enough to control valid code in their own Worker and have it placed in the same process as the victim Worker.

The leak does not involve an ordinary memory-read instruction. Spectre exploits speculative execution and the indirect effects it leaves in the cache and other internal processor structures. By repeating measurements, an attacker can reconstruct bits of data they should not be able to access.

In theory, potential targets include authentication tokens, keys, and other secrets temporarily held in a tenant’s heap. The demonstration involved a JWT, not real customer data.

WebSockets and Durable Objects Bypassed Operational Defenses

Workers restricts the timing functions available to scripts. During CPU execution, some time sources are frozen or made less precise; scripts also lack shared memory and multithreading.

The researchers used WebSockets as a remote clock. Connection traffic and response times provided a sufficient reference for distinguishing signals produced by speculative execution, even without a high-precision local timer.

A second factor involved Durable Objects. These components can keep a single isolate active for periods ranging from five to more than 20 hours. Such long runtimes give an attacker enough time to collect many measurements and gradually improve accuracy.

The Dynamic Process Isolation architecture, or DyPrIs, is intended to move suspicious scripts into a separate process after an invocation ends. According to the tests, however, a prolonged Durable Object invocation could continue before isolation was applied.

Heavy WebSocket use also generated substantial activity in the instruction translation lookaside buffer, or iTLB. This reduced the branch-misprediction signal—the signal produced by incorrect branch predictions—below the threshold DyPrIs used to identify anomalous behavior.

Cloudflare described the issue as a limitation in the DyPrIs implementation. The researchers instead consider it a more structural weakness: detection occurred too late and relied on a signal that I/O activity could attenuate.

Performance Measured on AMD Processors

The production tests were conducted on Linux servers equipped with AMD EPYC Zen 2 and Zen 3 processors. Measurements were intentionally performed overnight, when CPU utilization ranged from 10% to 25%.

These conditions favored signal collection. Under heavier loads, the exfiltration rate decreased, but the attack did not become impossible; it simply proceeded more slowly.

Previous work by Cloudflare and TU Graz, published in 2021, achieved 120 bits per hour. That research introduced DyPrIs as a defense and reported a 0.61% false-positive rate, claiming that the mechanism provided statistical guarantees comparable to strict process isolation against the Spectre attacks evaluated at the time.

The new demonstration shows that those guarantees depended on the threat model and operating conditions considered. It does not show that every Worker is automatically exposed, but it confirms that in-process isolation requires multiple defenses and continuous detection.

Countermeasures Applied by Cloudflare

Cloudflare stated that it mitigated the attack in production by combining three mechanisms:

  • a hardened version of DyPrIs;
  • integration of the V8 Sandbox;
  • in-process isolation based on Memory Protection Keys, or MPK.

The V8 Sandbox restricts transient access to 64-bit pointers. MPK adds hardware-enforced protection by placing Worker heaps behind dedicated keys.

Modern x64 systems have approximately 12 keys available for this purpose. The platform combines MPK, the V8 Sandbox, and a rotating memory layout to prevent neighboring sandboxes from sharing the same key.

A description of the measures published by Cloudflare in September 2025 indicated that random key assignment alone would block approximately 92% of cross-isolate accesses. However, a collision remained possible: two isolates could receive the same key. The rotating layout removes this gap within the threat model covered by the sandbox.

The defense therefore does not rely solely on attack detection. Even if a signal were masked by WebSocket traffic or a long-running invocation, hardware controls and heap separation should prevent access across contexts.

What Customers Need to Know

No specific affected Cloudflare Workers versions have been disclosed, nor has Cloudflare identified a software update that customers must install manually. The stated mitigation applies to the provider’s production infrastructure.

It is not known whether the case has been assigned a CVE identifier or appears in CISA’s Known Exploited Vulnerabilities catalog. No catalog entry date or remediation deadline has been reported to administrators.

For customers, the theoretical risk primarily concerns secrets held in memory by Workers potentially co-located with malicious code. It is prudent to reduce token lifetimes, limit their privileges, and rotate the most sensitive credentials. However, these measures do not correct the underlying isolation issue.

Cloudflare has not reported active compromises. As a result, there are no specific public indicators to search for in customer logs. Organizations should nevertheless review for anomalous access to services protected by JWTs and rotate tokens if suspicious activity emerges, without automatically attributing every anomaly to this attack.

Read next

Sources

This article is an original reworking based on the sources below.

Related topicsCloudflare WorkersSpectre attackJWTdata exfiltrationside-channel attackWebSocketsDurable Objectssecurity countermeasures
Back to home