Onderzoekers hebben details gedeeld over een remote Spectre lekkage tegen Cloudflare Workers. Daarbij is in een productie-achtige opzet een JSON Web Token (JWT) uit het geheugen van een “victim” Worker kunnen worden uitgelezen. De onderzoekers rapporteren een maximale leksnelheid van 12 bits per seconde, wat volgens hen veel sneller is dan een eerdere demonstratie uit 2021.
Belangrijk: in het experiment is de JWT bewust in het geheugen geplaatst en de onderzoekers geven aan dat geen klantdata is benaderd. Wel raakt het onderwerp een kernvraag: hoe robuust is geheugenisolatie wanneer meerdere tenants dezelfde runtime en hetzelfde proces delen?
Wat is de aanval en hoe werkt de Spectre lekkage?
De proef draait om twee Workers: een aanvaller en een slachtoffer, beide gecontroleerd door de onderzoekers. De JWT werd in het geheugen van de victim Worker geplaatst. Vervolgens probeerde de attacker Worker informatie te reconstrueren via een Spectre-achtige timingaanpak.
Cloudflare legt uit dat Workers code van meerdere tenants draaien in afzonderlijke V8-isolates binnen hetzelfde operating-system proces. Dat betekent dat de scheiding grotendeels leunt op taal- en runtime-isolatie, en niet op strikte process-isolatie.
Volgens Cloudflare kan een geheugenlezen binnen hetzelfde Worker-proces leiden tot cross-tenant leakage. De aanval vereist bovendien dat de attacker- en victim-Workers co-located zijn in afzonderlijke V8-isolates binnen dat ene proces.
Waarom is dit relevant: co-locatie en procesdelen
Cloudflare Workers is ontworpen om snel te starten en om meerdere omgevingen efficiënt te draaien. In de besproken architectuur betekent dat: minder overhead dan bij volledige process isolation, maar ook afhankelijkheid van de beveiligingsmaatregelen rondom detectie en in-process afscherming.
In de paper staat dat de productieimplementatie van een verdedigingsmechanisme, dat verdachte scripts moet isoleren, niet voldoende bleek voor deze specifieke aanpak. Dat zet de toon voor de discussie: niet alleen “kan het?”, maar ook “ziet het systeem het op tijd genoeg?”.
Timing als sleutel: WebSocket en Durable Objects
Een Spectre-aanval draait vaak om het uitbuiten van subtiele verschillen in uitvoeringstijd. In dit onderzoek noemen de onderzoekers WebSocket-communicatie als mogelijkheid om een remote timingbron te leveren.
Daarnaast wordt Durable Objects genoemd: daarmee kan een Worker-isolate lang genoeg in leven worden gehouden om de timingobservaties te herhalen. De onderzoekers beschrijven dat Durable Objects een single Worker isolate kunnen laten doorlopen van vijf tot meer dan 20 uur.
Dat is relevant omdat de verdediging rondom isolatie in dit scenario pas ingrijpt na een invocation. De onderzoekers stellen dat een long-lived Durable Object invocation kan doorlopen voordat de isolation plaatsvindt.
DyPrIs onder druk: detectie versus suppressie door I/O
Cloudflare gebruikt Dynamic Process Isolation (DyPrIs) als detectie- en verdedigingslaag. Het mechanisme is bedoeld om verdachte scripts na een invocation in een apart proces te isoleren.
Volgens de onderzoekers kan zware WebSocket-gerichte input/output (I/O) de iTLB-activiteit (instruction translation lookaside buffer) verhogen. Daardoor daalt de genormaliseerde branch-misprediction-signaalsterkte die DyPrIs gebruikt. Het gevolg: het signaal kan onder de detectiedrempel zakken.
Cloudflare noemt het een limitation in de DyPrIs-implementatie. De onderzoekers stellen daar tegenover dat het eigenlijk gaat om fundamentele beperkingen van de detectiemethode, eerder dan om een “misconfiguratie” of een implementatiefout.
Hoe snel en hoe nauwkeurig was de lekkage?
De onderzoekers rapporteren een lekkage tot 12 bits per seconde met 99,16% nauwkeurigheid. Ter vergelijking noemen ze dat de eerdere aanval uit 2021 rond 2 bits per minuut zou zitten.
Ze geven ook aan dat hogere systeembelasting de leakage-rate verlaagt. Tegelijk blijft het volgens de onderzoekers onder hoge load mogelijk om langzamere aanvallen uit te voeren.
Voor de metingen werden Linux-servers gebruikt met AMD EPYC Zen 2 en Zen 3-processors. De tests zijn bewust uitgevoerd tijdens de nacht, met een CPU-gebruik tussen 10% en 25%, om volgens de onderzoekers de “beste” meetcondities te benaderen.
Wat deed Cloudflare om de Spectre lekkage te mitigeren?
Cloudflare stelt dat de aanval in productie al is gemitigeerd. Daarbij wijst het bedrijf op meerdere verbeteringen en hardeningmaatregelen:
- Verbeterde DyPrIs: Cloudflare zegt dat de detectiecapaciteit van het isolatiemechanisme is aangescherpt.
- V8 Sandbox: deze moet de toegang tot 64-bit pointers beperken.
- MPK-gebaseerde in-process isolatie: Worker-heaps worden achter hardware-enforced protection keys gezet. Cloudflare zegt dat moderne x64-systemen nog ongeveer 12 keys beschikbaar laten voor dit doel.
- Keycombinatie en roterende geheugenlayout: Cloudflare beschrijft dat het ontwerp de protection keys combineert met de V8 Sandbox en een roterende memory layout gebruikt om te voorkomen dat nabije sandboxes dezelfde key kunnen delen binnen het relevante dreigingsmodel.
In eerdere publicatie (september 2025) beschrijft Cloudflare dat random MPK-assignment op zichzelf ongeveer 92% van cross-isolate accesses zou “vangen”, omdat twee isolates dezelfde key zouden kunnen krijgen. De strengere roterende layout zou dat resterende gat moeten dichten voor het afgedekte in-sandbox dreigingsmodel.
Geen sandbox escape, maar wél een les over isolatie
Cloudflare benadrukt dat native code execution buiten het dreigingsmodel valt en dat de aanval niet afhankelijk is van een V8-softwarekwetsbaarheid of een sandbox escape. Dat maakt de case tegelijk interessant en frustrerend: zelfs zonder “klassieke exploit” kan er informatie lekken via subtiele micro-architectuurgedragingen en timing.
Het bedrijf noemt ook dat Workers lokale timingbronnen beperken door timers te bevriezen of te verscherpen tijdens CPU-uitvoering. Daarnaast zouden Worker-scripts geen gedeeld geheugen of multithreading krijgen.
Wat kun je als organisatie hiermee doen?
Voor organisaties die draaien op serverless-platforms en managed runtimes is de boodschap vooral: isolatie is geen zwart-wit begrip. Het gaat niet alleen om “kun je code draaien?”, maar ook om “welke signalen worden gemonitord” en “welke componenten maken timing mogelijk”.
Praktisch kun je je focus verleggen naar:
- Risicobeoordeling van co-locatie en welke isolatielagen de provider in productie gebruikt.
- Monitoring en patchbeleid voor platform- en runtimecomponenten (waar mogelijk via provider-updates).
- Secure engineering: zorg dat gevoelige secrets zoals JWT’s niet onnodig in context belanden die voor andere processen of tenants risico kunnen vergroten.
Als je wilt doorpakken op secure code en DevSecOps-principes, kan dit event interessant zijn: CodeSecCon: secure code & DevSecOps in één online event. Voor een breder beeld van aanvallen die draaien om slimme timing en omgeving, lees ook Phishing 3.0: van e-mailscans naar agent-gedreven aanval (context over hoe aanvallers steeds efficiënter worden in hun aanpak).
Conclusie
De aangekondigde Spectre lekkage laat zien dat zelfs bij moderne serverless-runtimes informatie kan lekken als de omstandigheden kloppen: co-locatie, een timingbron en een detectielaag die nét niet genoeg grip krijgt. De onderzoekers rapporteren daarbij hoge leksnelheden en sterke nauwkeurigheid in hun gecontroleerde experiment.
Cloudflare zegt de aanval al in productie te hebben gemitigeerd met verbeteringen aan DyPrIs, een V8 Sandbox-aanpak en MPK-gebaseerde in-process isolatie. Voor gebruikers blijft de kernvraag bestaan: hoe beter je inschat welke delen van je omgeving gevoelig zijn voor “micro-architectural” lekken, hoe gerichter je maatregelen kunt nemen.
Bron: https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html
