Eine neue Sicherheitsanalyse wirft erneut Fragen zur Robustheit sprach- statt prozessbasierter Isolation in Cloud-Umgebungen auf. Unter dem Namen Spectre-Leaks in Workers beschreiben Forschende einen Remote-Angriff auf Cloudflare Workers, bei dem bis zu 12 Bits pro Sekunde aus dem Speicher eines Opfers ausgelesen werden konnten – und dabei ein JSON Web Token (JWT) als Ziel diente.
Cloudflare widerspricht nicht der grundsätzlichen Richtung, betont jedoch, dass die Situation bereits in der Produktion entschärft wurde. Wie genau das Zusammenspiel aus Isolation, Timing-Quellen und Offsets funktioniert, lohnt sich genauer zu betrachten – gerade für Teams, die Multi-Tenant-Code auf derselben Laufzeitumgebung ausführen lassen.
So läuft der Versuch ab: Angreifer- und Opfer-Worker
Die Forschenden führten ein end-to-end Experiment durch. Dabei gab es einen Angreifer-Worker und einen Opfer-Worker, die beide von den Forschenden kontrolliert wurden. Das JWT wurde dabei bewusst im Speicher des Opfer-Workers platziert.
Wichtig: Laut der veröffentlichten Beschreibung wurde kein Kundendatensatz abgerufen. Das Ziel war es, die Möglichkeit einer Cross-Tenant-Leakage in der konkreten Workers-Umgebung nachzuweisen – nicht, reale personenbezogene Daten zu extrahieren.
Was an Spectre-Leaks in Workers besonders ist
Cloudflare ordnet das Problem als Limitation der bestehenden Dynamic Process Isolation (DyPrIs)-Schutzlogik ein. Kernaussage: Eine Speicher-Leseoperation innerhalb eines gemeinsam genutzten Worker-Prozesses kann unter bestimmten Bedingungen zu einem Leak zwischen Tenants führen.
Damit der Angriff funktioniert, müssen Angreifer- und Opfer-Worker co-lokalisiert sein: In getrennten V8 Isolates, aber dennoch innerhalb eines gemeinsamen Worker-Processes. Der Angreifer kontrolliert dabei gültigen Code im eigenen Isolate.
Außerdem gilt: Der Angriff hängt nicht von einer V8-Softwarelücke oder einem Sandbox-Escape ab. Native Code-Ausführung war zudem nicht Teil des Bedrohungsmodells.
Warum der Schutz ins Wanken geriet: DyPrIs, Timing und I/O
Die Workers-Plattform versucht, sensiblen Verhalten über DyPrIs zu erkennen und verdächtige Skripte nach dem Ende einer Ausführung in einen separaten Prozess zu verschieben. Die Forschenden fanden jedoch Hinweise darauf, dass eine lang laufende Durable-Object-Ausführung einen Zustand erzeugen kann, in dem die Isolation nicht rechtzeitig greift.
Zusätzlich identifizierten sie eine WebSocket-basierte Kommunikation als mögliche Remote-Timing-Quelle. Gerade Timing-Informationen sind für Spectre-ähnliche Muster entscheidend, weil sie Rückschlüsse aus subtilen Ausführungsunterschieden ermöglichen.
Weiter kam ein Praxisfaktor hinzu: WebSocket-lastiges I/O erhöhte laut Analyse die iTLB-Aktivität (instruction translation lookaside buffer). Dadurch sinkt das normalisierte Branch-Misprediction-Signal, das DyPrIs als Detektionsgrundlage nutzt, unter den Schwellenwert.
Mit anderen Worten: Nicht nur die Isolation an sich, sondern auch die Art, wie Eingaben und Ausgaben getaktet bzw. „verrauscht“ werden, kann die Detektionsfähigkeit beeinflussen.
Wie viel wurde geleakt? Zahlen aus der Analyse
Die Forschenden berichten von einer Leckrate von bis zu 12 Bits pro Sekunde bei einer Genauigkeit von 99,16%. Im Vergleich dazu lag die Rate bei einem früheren Angriff aus dem Jahr 2021 bei 2 Bits pro Minute – die aktuelle Demonstration war also deutlich schneller.
Interessant ist auch, dass die Forscher eine Labor-Situation beschrieben haben, in der der CPU-Lastzustand besonders „günstig“ war. Die Tests liefen auf Linux-Servern mit AMD EPYC Zen 2 und Zen 3. Gemessen wurde absichtlich in der Nacht, als die CPU-Nutzung zwischen 10% und 25% lag.
Gleichzeitig gilt: Höhere Systemlast reduzierte die Leckrate. Dennoch blieben laut Bericht langsamer verlaufende Angriffe auch unter hoher Last möglich.
Einordnung: Was Cloudflare sagt – und welche Änderungen umgesetzt wurden
Cloudflare führt aus, dass die betreffende Angriffsseite bereits in der Produktion abgefangen wird. Laut Unternehmen haben mehrere technische Maßnahmen zusammengewirkt:
- Verbesserte DyPrIs: Die Erkennungsfähigkeit des bestehenden Isolationsmechanismus wurde erweitert.
- V8 Sandbox: Der Sandbox-Ansatz schränkt den Zugriff auf 64-bit Pointer transient ein.
- MPK-basierte In-Process-Isolation: Speicherbereiche der Worker-„Heaps“ werden hinter hardwareseitig durchgesetzten Protection Keys platziert.
Zur MPK-Umsetzung nennt Cloudflare außerdem Details zur Hardware: Moderne x64-Systeme lassen etwa 12 Keys für diesen Zweck übrig. Die Auslegung kombiniert die Keys mit der V8 Sandbox und nutzt einen rotierten Speicherlayout-Ansatz, um zu verhindern, dass benachbarte Sandboxes einen Key teilen.
Cloudflare verweist darauf, dass bereits eine zufallsbasierte MPK-Zuweisung einen großen Teil der Cross-Isolate-Zugriffe „einfängt“ – aber nicht alle. Daher wird das strengere Layout verwendet, um für das im „in-sandbox threat model“ abgedeckte Szenario die verbleibende Lücke zu schließen.
Warum die Diskussion trotzdem relevant bleibt
Die Veröffentlichung fällt in eine längere Linie. Laut Bericht ist die Offenlegung fast fünf Jahre nach früheren Arbeiten von Cloudflare und der TU Graz erfolgt, in denen ein Remote-Spectre-Angriff auf Workers demonstriert wurde und DyPrIs als Verteidigung eingeführt wurde.
In der früheren Studie wurde unter anderem eine False-Positive-Rate von 0,61% berichtet. Außerdem kam man zu dem Schluss, dass DyPrIs statistisch ähnliche Schutzgarantien wie eine strikt prozessbasierte Isolation bietet – allerdings bezogen auf die damals betrachteten Angriffe.
Die neue Arbeit stellt diesen Rahmen nicht pauschal in Frage, macht aber deutlich, dass Detektionsstrategien weiter gedacht werden müssen: Die Forschenden argumentieren, robuste Erkennung müsse während der Ausführung stattfinden und einen Signaltyp verwenden, der sich durch I/O-Aktivität nicht unterdrücken lässt.
Fazit: Spectre-Leaks in Workers als Weckruf für Isolationstiefe
Spectre-Leaks in Workers zeigen, wie anspruchsvoll moderne Multi-Tenant-Umgebungen sind, wenn Isolation vor allem auf Laufzeit- und Speichermodellen statt auf harte Prozessgrenzen setzt. Die Demonstration mit einem JWT verdeutlicht: Sobald Timing-Quellen, Lebensdauer-Mechanismen (wie Durable Objects) und Detektionslogik zusammenpassen, kann selbst „eigentlich geschützter“ Speicher unter Bedingungen lesbar werden.
Gleichzeitig betont Cloudflare, dass die konkrete Schwachstelle inzwischen in Produktion mitigiert ist und über die letzten drei Jahre keine Hinweise auf aktive Ausnutzung gefunden wurden. Für Betreiber und Entwickler bleibt jedoch die Kernbotschaft: Isolation ist nicht nur eine einzelne Komponente, sondern ein System aus Sandboxing, Speicherlayout, Hardware-Schutz und Erkennung während der Ausführung.
Quelle: https://thehackernews.com/2026/08/cloudflare-workers-spectre-attack-leaks.html
