Cloudflare Workers Spectre Side-Channel Leaks JWTs From Co-Located Workers — Detection and Mitigation Guide

Security researchers have demonstrated a working remote Spectre side-channel attack against Cloudflare Workers — the production, multi-tenant serverless platform — that leaked a JSON Web Token (JWT) from a co-located Worker at up to 12 bits per second. That rate is 360 times faster than the Spectre attack first demonstrated against this platform in 2021, collapsing a theoretical leak measured in days into one measured in minutes-to-hours for real credential material.

The end-to-end experiment used an attacker Worker and a victim Worker, both controlled by the researchers, co-located on the same physical infrastructure in Cloudflare's production environment. This is not a lab curiosity: it proves that speculative-execution side channels remain exploitable in hardened, sandboxed, multi-tenant serverless runtimes, and that secrets held in one tenant's isolate can be read by a hostile tenant on the same host.

If your organization runs Workers, service workers, or any multi-tenant serverless/FaaS compute where isolates share CPU cores, your secrets-in-memory exposure model just changed. This post covers how the attack works, what it means for your architecture, and what to do about it today.

What Happened

Researchers published an end-to-end proof-of-concept showing a malicious Cloudflare Worker co-located with a victim Worker could recover a JWT held in the victim's memory via a Spectre-style speculative-execution side channel. Key facts:

• Platform: Cloudflare Workers production environment (V8 isolate–based multi-tenant runtime).
• Victim secret: A JSON Web Token (JWT) resident in the co-located victim Worker's memory.
• Leak rate: Up to 12 bits per second — a 360x improvement over the ~0.033 bits/sec class of attack demonstrated against the same platform in 2021.
• Attacker requirements: The attacker only needs to deploy a Worker. No elevated privileges, no local access, no phishing — just a paid/free tenant slot scheduled onto the same host as a victim.
• Validation model: Both attacker and victim Workers were researcher-controlled, enabling ground-truth verification of the leaked bytes.

No CVE identifier has been published for this disclosure. The underlying vulnerability class traces back to Spectre (CVE-2017-5753 et al.), but the 2026 contribution is a practical, remote, high-bandwidth exploitation technique against a specific production platform — not a new silicon bug.

Why Defenders Should Care

The 2021 attack on this same platform was largely dismissed as too slow to matter operationally. At 12 bits/second, the math changes:

• A 256-bit secret (e.g., an HMAC signing key or compact JWT segment) can be recovered in ~21 seconds of stable co-location.
• A full JWT of typical size (several hundred bytes) is recoverable in minutes to tens of minutes, well within the TTL of many access tokens.
• Attackers don't need to target a specific victim Worker. In a multi-tenant platform, they can spray attacker Workers, co-locate with whatever tenants land on their host, and opportunistically harvest secrets — a "co-location lottery" attack model.

For CISOs and architects, the strategic lesson is this: process/isolate boundaries are not hardware memory boundaries. Any design that assumes "my secret is safe because it lives in a separate sandboxed isolate on shared silicon" must be re-evaluated for secret-in-memory exposure.

Technical Analysis: How the Attack Works

The Vulnerability Class

Spectre attacks exploit speculative execution: modern CPUs predict the outcome of branches and execute instructions ahead of retirement to keep pipelines full. When speculation is wrong, results are discarded architecturally — but microarchitectural traces remain, most notably in the CPU cache. An attacker who can (a) induce the victim's code to speculatively access secret-dependent memory, and (b) measure the resulting cache state, can infer the secret one bit or byte at a time.

Why Cloudflare Workers Is a Target-Rich Environment

Cloudflare Workers runs tenant code in V8 isolates — lightweight sandboxes sharing a single process (and thus a single address space and CPU core time-slices) rather than separate OS processes or VMs. This design is what makes Workers cheap and fast; it is also what makes it an attractive Spectre target:

1. Shared address space: Multiple tenants' data lives in one process. A Spectre gadget in the shared V8/runtime code — or in a co-tenant's code path — can speculatively read across tenant boundaries within that process.
2. Co-location by design: Tenants are scheduled onto shared hosts with no tenant control over placement. The attacker simply deploys and waits to be scheduled alongside victims.
3. JavaScript/WASM reachability: The attacker controls JIT-compiled code running in the same process, giving them the primitives needed to train branch predictors and probe cache state.

The 2026 Breakthrough: Bandwidth

The hard problem in remote Spectre attacks has always been the covert channel's clock. Reading cache state requires a high-resolution timer, and platforms like Cloudflare deliberately degraded timer precision after 2021. The researchers' 360x speedup implies a meaningful advance in the measurement side channel — recovering timing resolution (or an equivalent side signal, such as contention-based amplification or repeated speculation sampling) sufficient to distinguish cache hits from misses at 12 bits/sec despite platform countermeasures. The disclosure indicates the attack functioned against the current production configuration, meaning prior mitigations (timer degradation, site isolation within the isolate model) were insufficient against the refined technique.

Exploitation Status

• In-the-wild exploitation: None reported. This is a coordinated research disclosure.
• PoC status: End-to-end PoC validated by researchers against production infrastructure using researcher-controlled attacker and victim Workers.
• CISA KEV: Not listed (no CVE assigned).
• Vendor response: Organizations should monitor the Cloudflare blog and Cloudflare changelog for mitigation statements. Historically, Cloudflare has responded to Spectre-class research by hardening timer precision, isolate scheduling, and V8 mitigations.

Treat this as pre-weaponization intelligence: the technique is published, the bandwidth is operationally viable, and the barrier to entry (deploy a Worker) is trivial. Defensive action should not wait for confirmed abuse.

Detection & Response

A candid assessment first: you cannot signature a speculative-execution side channel at the endpoint. The attack leaves no file, no process anomaly, no network IOC inside the victim. Detection must operate at three realistic layers: (1) tenant/Worker behavior anomalies on the platform, (2) exfiltration of the recovered secret, and (3) post-compromise use of a stolen JWT. The rules below target layers 2 and 3, where defenders actually have telemetry.

SIGMA Rules

The most reliable observable in this attack chain is where the stolen JWT goes next: exfiltration from the attacker Worker to attacker infrastructure, and replay of the token from anomalous sources. These rules target those behaviors.

---
title: JWT Token Observed in Outbound URL or Query String
tid: 3f9a1c44-7b2e-4d18-9f6a-2c8e5b1d4a07
status: experimental
description: Detects JSON Web Tokens (base64url header 'eyJ') transmitted in URL paths or query strings, a pattern consistent with credential exfiltration from serverless/edge compute to external endpoints. JWTs should almost never traverse URLs.
references:
  - https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html
  - https://attack.mitre.org/techniques/T1552/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.credential_access
  - attack.t1552
  - attack.exfiltration
logsource:
  category: proxy
detection:
  selection:
    c-uri|contains:
      - 'eyJhbGciOi'
      - 'eyJ0eXAiOi'
      - 'eyJraWQiOi'
  filter_known_auth_flows:
    c-uri|contains:
      - '/oauth'
      - '/sso'
      - '/saml'
      - '/callback'
  condition: selection and not filter_known_auth_flows
falsepositives:
  - Legitimate OAuth/OIDC flows passing tokens as query parameters (filtered above; tune per IdP)
  - Password reset links embedding signed tokens
level: high
---
title: JWT Replay From Anomalous Source ASN or Geography
tid: 8c2e6f19-4a3d-4e87-bb51-9d0f2a6c3e15
status: experimental
description: Detects authentication events where the same token/session identifier is used from two or more distinct source ASNs or countries within a short window, consistent with a stolen JWT being replayed by an attacker after side-channel recovery.
references:
  - https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html
  - https://attack.mitre.org/techniques/T1550/004/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.lateral_movement
  - attack.t1550.004
logsource:
  category: authentication
detection:
  selection:
    Outcome: 'success'
  condition: selection
falsepositives:
  - Users on mobile networks roaming between carriers
  - Corporate VPN egress across multiple PoPs
level: medium
---
title: Outbound Request From Edge/Serverless Runtime to Rare External Host
tid: 5d1b8e02-9c47-4a6f-ae23-7f4c9d2b8016
status: experimental
description: Detects serverless or edge compute workloads initiating outbound connections to hosts with no prior baseline in the environment, consistent with an attacker Worker exfiltrating recovered secret material via fetch() to attacker-controlled infrastructure.
references:
  - https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html
  - https://attack.mitre.org/techniques/T1567/
author: Security Arsenal
date: 2026/08/15
tags:
  - attack.exfiltration
  - attack.t1567
logsource:
  category: dns
detection:
  selection:
    query|contains:
      - '.workers.dev'
  filter_rare_external:
    query|contains:
      - 'cloudflare.com'
      - 'workers.cloudflare.com'
  condition: selection and not filter_rare_external
falsepositives:
  - Developers testing third-party Workers endpoints
  - Legitimate inter-Worker service bindings (prefer service bindings over public fetch)
level: low

Note on the third rule: it is intentionally low severity and designed as a baselining rule, not an alert. Deploy it to build the allowlist of legitimate Worker-to-Worker traffic, then graduate unknowns.

KQL — Microsoft Sentinel / Defender

The highest-fidelity hunt available to most SOCs is stolen-JWT replay detection: the same token used from divergent infrastructure. This query works against any identity/provider logs ingested into Sentinel (Entra ID sign-in logs shown; adapt SigninLogs to your IdP's table).

// Hunt: Same JWT/session replayed from multiple ASNs or countries within 4 hours
// Consistent with token theft (e.g., side-channel recovery) followed by attacker replay
let lookback = 7d;
let replay_window = 4h;
SigninLogs
| where TimeGenerated > ago(lookback)
| where ResultType == 0
| where isnotempty(SessionId) or isnotempty(TokenIssuerType)
| summarize 
    Locations = make_set(Location),
    IPs = make_set(IPAddress),
    ASNCount = dcount(NetworkLocationDetails),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)
  by UserPrincipalName, SessionId, bin(TimeGenerated, replay_window)
| where array_length(Locations) > 1 or array_length(IPs) > 1
| project UserPrincipalName, SessionId, Locations, IPs, FirstSeen, LastSeen
| order by LastSeen desc;

// Supplement: rare outbound destinations from serverless/edge compute (via CEF/Syslog ingestion of egress firewall logs)
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DeviceVendor has_any ("Cloudflare", "Zscaler", "Palo Alto") or DeviceProduct has "firewall"
| summarize FirstSeen = min(TimeGenerated), Count = count() by DestinationHostName, SourceIP
| where Count < 5  // rare destinations from this source
| order by FirstSeen desc;

Tune the first query's SessionId field to whatever token-correlation field your IdP emits (Entra UniqueTokenIdentifier, Okta authenticationContext.externalSessionId, etc.). Token replay from impossible-travel infrastructure is your strongest post-compromise signal.

Velociraptor VQL — Developer Workstation and Pipeline Audit

Endpoint forensics is warranted on the deployment side: auditing developer workstations and CI runners for Worker code containing the primitives this attack requires (tight timing loops, cache-probing patterns). This is a supply-chain-style hunt — find hostile or compromised Worker source before it deploys.

-- Hunt for Worker/JavaScript source containing Spectre-style timing and cache-probing primitives
-- Targets developer workstations and CI/CD build agents
SELECT FullPath, Size, Mtime, 
       grep(pattern="performance\\.now|SharedArrayBuffer|Atomics|measure.*cache|prime.*probe", 
            file=FullPath) AS Matches
FROM glob(globs=[
  "C:/Users/*/**/worker*.js",
  "C:/Users/*/**/*.worker.js",
  "C:/Users/*/**/wrangler.toml",
  "/home/*/**/worker*.js",
  "/home/*/**/wrangler.toml"
])
WHERE Matches 
  AND FullPath !~ "node_modules"
ORDER BY Mtime DESC

Legitimate Workers rarely combine performance.now() measurement loops with SharedArrayBuffer/Atomics in tight instrumentation patterns. Hits on this hunt in CI agents or developer machines warrant code review, not automatic blocking.

Remediation / Hardening Script

This Bash script audits your Cloudflare Workers estate via the API: enumerates deployed Workers, flags Workers with no recent deployment activity (stale attack surface), and inventories secret bindings that should be rotated given in-memory exposure risk.

#!/bin/bash
# Cloudflare Workers security audit — post-Spectre side-channel disclosure
# Requires: CF_API_TOKEN (Workers:Read, Account Settings:Read), CF_ACCOUNT_ID
set -euo pipefail

CF_API="https://api.cloudflare.com/client/v4"
AUTH="Authorization: Bearer ${CF_API_TOKEN}"

echo "=== [1] Enumerating all Workers scripts ==="
curl -s -H "$AUTH" "${CF_API}/accounts/${CF_ACCOUNT_ID}/workers/scripts" \
  | jq -r '.result[] | "\(.id)\tcreated:\(.created_on)\tmodified:\(.modified_on)"'

echo ""
echo "=== [2] Flagging Workers unmodified in 90+ days (stale, unpinned attack surface) ==="
cutoff=$(date -d '90 days ago' +%s 2>/dev/null || date -v-90d +%s)
curl -s -H "$AUTH" "${CF_API}/accounts/${CF_ACCOUNT_ID}/workers/scripts" \
  | jq -r '.result[] | [.id, .modified_on] | @tsv' | while IFS=$'\t' read -r id mod; do
    mod_epoch=$(date -d "$mod" +%s 2>/dev/null || date -j -f "%Y-%m-%dT%H:%M:%S" "${mod%%.*}" +%s)
    if [ "$mod_epoch" -lt "$cutoff" ]; then
      echo "STALE: $id (last modified $mod) — review necessity, redeploy on current runtime"
    fi
done

echo ""
echo "=== [3] Inventorying Workers with secrets (rotation candidates) ==="
# Any secret that lived in isolate memory is theoretically exposed to a co-located attacker.
# Rotate high-value secrets (JWT signing keys, API tokens, DB creds) per your risk model.
for script in $(curl -s -H "$AUTH" "${CF_API}/accounts/${CF_ACCOUNT_ID}/workers/scripts" | jq -r '.result[].id'); do
  secrets=$(curl -s -H "$AUTH" "${CF_API}/accounts/${CF_ACCOUNT_ID}/workers/scripts/${script}/secrets")
  count=$(echo "$secrets" | jq '.result | length')
  if [ "$count" -gt 0 ]; then
    echo "$script has $count secret binding(s): $(echo "$secrets" | jq -r '.result[].name' | tr '\n' ' ')"
  fi
done

echo ""
echo "=== [4] Checking for Workers still on legacy compatibility dates ==="
# Older compatibility_date values may lack newer V8/runtime mitigations.
curl -s -H "$AUTH" "${CF_API}/accounts/${CF_ACCOUNT_ID}/workers/scripts" \
  | jq -r '.result[].id' | while read -r id; do
    settings=$(curl -s -H "$AUTH" "${CF_API}/accounts/${CF_ACCOUNT_ID}/workers/scripts/${id}/settings" 2>/dev/null || true)
    echo "$id: $(echo "$settings" | jq -r '.result.compatibility_date // "n/a"' 2>/dev/null || echo "check manually")"
done

echo ""
echo "Done. Rotate secrets on any Worker handling JWTs, signing keys, or session material."

Remediation and Mitigation

1. Shorten Token Lifetimes — This Is Your Highest-Value Control

At 12 bits/sec, the attacker's economics are governed by your token TTL. A JWT with a 60-minute TTL recovered in 10 minutes gives the attacker 50 minutes of replay. A JWT with a 5-minute TTL recovered in 10 minutes is already dead.

• Set access token TTLs to 5 minutes or less for Workers-adjacent services.
• Pair short TTLs with refresh token rotation and reuse detection (available in most modern IdPs).
• Where supported, move to sender-constrained tokens — DPoP (RFC 9449) or mTLS-bound tokens — so a recovered JWT is useless without the corresponding private key.

2. Keep Secrets Out of Isolate Memory Where Possible

• Prefer request-time secret retrieval from Cloudflare's Secrets Store or an external vault over long-lived module-scope variables. A secret that enters isolate memory only transiently narrows the speculation window.
• Never embed JWT signing keys or long-lived tokens in Worker source or static environment variables. Use secret bindings, and rotate them on the assumption that in-memory exposure is possible.
• For token validation, prefer asymmetric verification (JWKS/public key) at the edge so the signing private key never lives in a Worker at all.

3. Segment Your Tenant Blast Radius

• Isolate Workers that handle high-value secrets onto separate Cloudflare accounts from general-purpose or experiment workloads. Co-location risk is per-host; account separation does not guarantee host separation, but it reduces scheduling overlap with noisy neighbors and gives you cleaner audit boundaries.
• Use service bindings (direct Worker-to-Worker channels) instead of public fetch() between your own Workers — this both improves security and reduces the exfiltration surface.
• Audit and decommission stale Workers. Every dormant script is co-location surface with no defender watching it.

4. Update Compatibility Dates and Runtime

Cloudflare ships V8 and runtime mitigations continuously, gated by each Worker's compatibility_date. Workers pinned to old compatibility dates do not receive newer runtime hardening. Audit (script above) and advance compatibility dates to current after testing. Monitor the Cloudflare changelog for Spectre-related runtime updates responding to this disclosure.

5. Detect Post-Compromise, Not the Channel

You will not detect the side channel. You can detect what follows:

• Token replay analytics (KQL above) across your IdP.
• Egress baselining for anything reaching out from edge compute contexts.
• Impossible-travel and ASN-divergence alerts tuned tightly for service accounts, which should authenticate from fixed infrastructure.
• Feed your Workers audit logs (available via Cloudflare Logpush) into your SIEM and alert on unexpected new script deployments — an attacker needs to deploy code to attack you, and unauthorized Worker deployment is a detectable, high-signal event.

6. Architectural Takeaway for Your Broader Serverless Estate

This finding is not Cloudflare-specific. Any multi-tenant FaaS, edge compute, or shared-isolate platform (and, more broadly, any shared-silicon tenancy including standard cloud VMs) carries speculative-execution residual risk. Apply the same controls portfolio-wide: short credential TTLs, sender-constrained tokens, minimal in-memory secret dwell time, and post-compromise replay detection. Treat "secrets in shared-tenant memory" as a standing risk register item, not a closed 2018-era issue.

Bottom Line

A 360x bandwidth improvement turns Spectre from a research footnote into an operationally viable credential-theft primitive against production serverless multi-tenancy. There is no patch for speculative execution; there is only engineering around it. Shorten your token lifetimes, constrain your tokens to senders, minimize secrets' time in isolate memory, rotate what was exposed, and shift detection to token replay and unauthorized Worker deployment. Do it this quarter, not after the first confirmed in-the-wild campaign.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub