Cloudflare Workers: Spectre exfiltriert ein JWT mit 12 Bit pro Sekunde

Erfolgreicher Remote-Angriff in einer Produktionsumgebung

Sicherheitsforscher haben einen Remote-Spectre-Angriff auf Cloudflare Workers demonstriert, mit dem sich ein JSON Web Token aus dem Speicher eines Opfer-Workers auslesen ließ. Das Experiment wurde am 19. August 2026 entdeckt.

Die maximale Geschwindigkeit betrug 12 Bit pro Sekunde bei einer Genauigkeit von 99,16 %. Damit lag das Ergebnis rund 360-mal höher als der 2021 dokumentierte Wert, als ein vergleichbarer Angriff 2 Bit pro Minute erreichte.

Der Versuchsaufbau bestand aus zwei Workern: einem vom Angreifer kontrollierten und einem als Ziel dienenden Worker. Die Forscher platzierten das JWT absichtlich im Speicher des zweiten Workers und versuchten anschließend, es anhand der Spuren der spekulativen Prozessorausführung zu rekonstruieren.

Der Test fand auf realer Cloudflare-Infrastruktur statt, betraf jedoch keine Kundendaten. Cloudflare erklärte außerdem, in den vergangenen drei Jahren keine Hinweise auf eine aktive Ausnutzung festgestellt zu haben.

Warum die Isolation von Workern mandantenübergreifende Datenlecks ermöglichen kann

Cloudflare Workers führt den Code verschiedener Kunden in getrennten V8-Isolates aus. Diese Isolates trennen den Ausführungskontext auf Sprachebene, können jedoch im selben Betriebssystemprozess liegen.

Diese Architektur reduziert die Startlatenz gegenüber einem separaten Prozess für jeden Worker. Sie schafft jedoch eine andere Angriffsfläche: Eine mikroarchitektonische Schwachstelle wie Spectre kann es ermöglichen, Informationen aus dem Speicher eines anderen, gemeinsam untergebrachten Isolates abzuleiten.

Der Angreifer muss weder nativen Code ausführen noch V8 kompromittieren oder die Sandbox verlassen. Es genügt, dass er gültigen Code in seinem eigenen Worker kontrolliert und dieser im selben Prozess wie der Opfer-Worker ausgeführt wird.

Bei dem Datenabfluss handelt es sich nicht um einen gewöhnlichen Speicherlesevorgang. Spectre nutzt spekulative Ausführung und indirekte Spuren, die im Cache und in anderen internen Prozessorstrukturen hinterlassen werden. Durch wiederholte Messungen kann der Angreifer Datenbits rekonstruieren, auf die er eigentlich keinen Zugriff haben dürfte.

Theoretisch könnten zu den Zielen Authentifizierungstoken, Schlüssel oder andere Geheimnisse gehören, die sich vorübergehend im Heap eines Mandanten befinden. Die Demonstration betraf ein JWT und keine echten Kundendaten.

WebSockets und Durable Objects umgingen die operativen Schutzmaßnahmen

Workers schränkt die für Skripte verfügbaren Zeitmessfunktionen ein. Während der CPU-Ausführung werden bestimmte Zeitquellen eingefroren oder ungenauer gemacht. Außerdem verfügen die Skripte weder über Shared Memory noch über Multithreading.

Die Forscher nutzten WebSockets als entfernte Uhr. Der Datenverkehr und die Antwortzeiten der Verbindung lieferten eine ausreichende Referenz, um die durch spekulative Ausführung erzeugten Signale zu unterscheiden – auch ohne lokalen Hochpräzisionstimer.

Ein weiterer Faktor waren die Durable Objects. Diese Komponenten können ein einzelnes Isolate zwischen fünf und mehr als 20 Stunden aktiv halten. Ein derart langer Zeitraum gibt dem Angreifer genügend Zeit, zahlreiche Messungen zu sammeln und die Genauigkeit schrittweise zu verbessern.

Die Erkennungstechnologie Dynamic Process Isolation (DyPrIs) soll verdächtige Skripte nach Abschluss eines Aufrufs in einen separaten Prozess verschieben. Den Tests zufolge konnte ein lang andauernder Aufruf eines Durable Objects jedoch fortgesetzt werden, bevor die Isolation angewendet wurde.

Die intensive Nutzung von WebSockets erzeugte außerdem erhebliche Aktivität im Instruction Translation Lookaside Buffer (iTLB). Dadurch wurde das Signal von Branch Mispredictions, also Fehlvorhersagen bei Sprüngen, unter den von DyPrIs verwendeten Schwellenwert zur Erkennung anomalen Verhaltens gedrückt.

Cloudflare bezeichnete das Problem als Einschränkung der DyPrIs-Implementierung. Die Forscher sehen darin dagegen eine strukturellere Schwäche: Die Erkennung erfolgte zu spät und beruhte auf einem Signal, das durch I/O-Aktivität abgeschwächt werden konnte.

Gemessene Leistung auf AMD-Prozessoren

Die Produktionstests wurden auf Linux-Servern mit AMD-EPYC-Prozessoren der Generationen Zen 2 und Zen 3 durchgeführt. Die Messungen fanden absichtlich nachts statt, als die CPU-Auslastung zwischen 10 und 25 % lag.

Diese Bedingungen erleichterten die Erfassung des Signals. Bei höherer Auslastung sank die Exfiltrationsgeschwindigkeit, der Angriff wurde jedoch nicht unmöglich – er verlief lediglich langsamer.

Die frühere, 2021 veröffentlichte Arbeit von Cloudflare und der TU Graz hatte 120 Bit pro Stunde erreicht. Diese Untersuchung führte DyPrIs als Schutzmaßnahme ein und nannte eine False-Positive-Rate von 0,61 %. Sie kam zu dem Schluss, dass der Mechanismus bei den damals bewerteten Spectre-Angriffen statistische Garantien bot, die mit einer strikten Prozessisolation vergleichbar waren.

Die neue Demonstration zeigt, dass diese Garantien vom Angriffsmodell und den berücksichtigten Betriebsbedingungen abhingen. Sie belegt nicht, dass jeder Worker automatisch gefährdet ist, bestätigt jedoch, dass In-Process-Isolation mehrere Schutzmechanismen und eine kontinuierliche Erkennung erfordert.

Die von Cloudflare umgesetzten Gegenmaßnahmen

Cloudflare erklärte, den Angriff in der Produktion durch die Kombination von drei Mechanismen mitigiert zu haben:

• eine gehärtete Version von DyPrIs;
• die Integration der V8 Sandbox;
• In-Process-Isolation auf Basis von Memory Protection Keys (MPK).

Die V8 Sandbox beschränkt den vorübergehenden Zugriff auf 64-Bit-Zeiger. MPK ergänzt einen hardwarebasierten Schutz, indem die Heaps der Worker hinter spezifischen Schlüsseln platziert werden.

Auf modernen x64-Systemen stehen für diesen Zweck noch etwa 12 nutzbare Schlüssel zur Verfügung. Die Plattform kombiniert MPK, die V8 Sandbox und eine rotierende Speicheranordnung, damit benachbarte Sandboxes nicht denselben Schlüssel gemeinsam verwenden.

Eine im September 2025 von Cloudflare veröffentlichte Beschreibung der Maßnahmen besagte, dass allein die zufällige Schlüsselzuweisung etwa 92 % der Zugriffe zwischen Isolates verhindert hätte. Es blieb jedoch eine Kollisionsmöglichkeit: Zwei Isolates konnten denselben Schlüssel erhalten. Die rotierende Anordnung beseitigt diese Lücke innerhalb des vom Sandbox-Modell abgedeckten Bedrohungsmodells.

Die Abwehr beruht daher nicht ausschließlich auf der Erkennung des Angriffs. Selbst wenn ein Signal durch WebSocket-Datenverkehr oder einen lang andauernden Aufruf verborgen würde, sollten die Hardwarekontrollen und die Trennung der Heaps den Zugriff zwischen den Kontexten verhindern.

Was Kunden wissen sollten

Konkrete Versionen von Cloudflare Workers, die betroffen sind, wurden nicht genannt. Ebenso wurde kein Software-Update angegeben, das manuell installiert werden müsste. Die erklärte Mitigation betrifft die Produktionsinfrastruktur des Providers.

Unklar ist, ob der Fall mit einer CVE-Kennung verknüpft ist oder im Katalog Known Exploited Vulnerabilities der CISA geführt wird. Auch ein Aufnahmedatum in den Katalog oder eine Frist zur Behebung für Administratoren wurde nicht genannt.

Für Kunden betrifft das theoretische Risiko vor allem Geheimnisse, die von potenziell gemeinsam mit schädlichem Code ausgeführten Workern im Speicher gehalten werden. Es ist ratsam, die Lebensdauer von Token zu verkürzen, ihre Berechtigungen zu beschränken und besonders sensible Zugangsdaten regelmäßig zu rotieren. Diese Maßnahmen beheben jedoch nicht die zugrunde liegende Isolationsproblematik.

Cloudflare meldete keine aktiven Kompromittierungen. Daher gibt es keine spezifischen öffentlichen Indikatoren, nach denen Kunden in ihren Logs suchen könnten. Organisationen sollten dennoch auf ungewöhnliche Zugriffe auf durch JWTs geschützte Dienste prüfen und Token rotieren, wenn verdächtige Aktivitäten festgestellt werden, ohne jede Anomalie automatisch diesem Angriff zuzuschreiben.