Cloudflare: Fehler in GLM-5.3 legte 155 Antworten über Mandantensitzungen hinweg offen

Cloudflare veröffentlichte am 26. Oktober 2026 einen Bericht zum Vorfall, in dem das Unternehmen eine anfrageübergreifende Offenlegung des KV-Caches im Modell GLM-5.3 auf seiner Plattform Workers AI bekannt gab. Dabei enthielten 155 Antworten auf sehr lange Prompts Daten aus den Sitzungen anderer Kunden.

Der Sicherheitsforscher Gadi Evron von Knostic meldete Cloudflare das Problem mit der Mandantenisolierung am 8. September 2026 über das HackerOne-Programm des Unternehmens. Die Offenlegung betraf das Modell, das unter @cf/zai-org/glm-5.3 bereitgestellt wurde, und bestand seit dem 27. August 2026, dem Tag, an dem GLM 5.3 auf Workers AI eingeführt wurde. Cloudflare behob das Problem und stellte das Modell am 9. September 2026 wieder bereit. Nach eigenen Angaben bestätigte das Unternehmen, dass kein anderes auf Workers AI gehostetes Modell betroffen war.

Alle 155 betroffenen Antworten gingen auf Prompts mit mehr als 681.280 Tokens zurück. Cloudflare erklärte, dass die von dem Unternehmen identifizierten Anfragen – nach Ausschluss der eigenen Tests und der Anfragen des Forschers – hinsichtlich Zeitpunkt und Umfang einer gewöhnlichen Nutzung langer Kontextfenster entsprachen und nicht auf wiederholte Ausnutzung des Fehlers hindeuteten. Das Unternehmen fand keine Hinweise auf eine gezielte Ausnutzung.

Die beiden Ursachen der Offenlegung

GLM ist ein Textgenerierungsmodell von Z.ai, das für Workflows zum agentischen Programmieren entwickelt wurde und zu den vielen Modellen gehört, die über Workers AI verfügbar sind. Cloudflare betreibt GLM 5.3 mit SGLang, einer quelloffenen Inferenz-Engine, in einer disaggregierten Konfiguration: Prefill-GPUs verarbeiten den Prompt und erzeugen dessen KV-Cache. Anschließend übertragen sie diesen per direktem Speicherzugriff über RDMA (Remote Direct Memory Access) mithilfe von Mooncake an Decode-GPUs, die die Antwort generieren. Der KV-Cache ist ein gemeinsamer Pool aus Seiten fester Größe. Da die Seiten zwischen Anfragen nicht auf null gesetzt werden, muss die Engine nachverfolgen, wem jede Seite gehört.

Dem Bericht zufolge ging die Offenlegung auf zwei Probleme zurück. Das erste war eine Fehlkonfiguration: Cloudflare setzte GLM 5.3 mit einem Kontextfenster von 1.048.576 Tokens ein, während der KV-Cache-Pool auf den Prefill-GPUs nur 681.280 Tokens fasste. Cloudflare erklärte, man habe die Abweichung bereits vor dem Start gekannt, aber erwartet, dass die Engine bei nicht verarbeitbaren Prompts einen Fehler zurückgeben würde. Da die Tests mit langen Kontexten erfolgreiche Antworten lieferten, habe das Unternehmen die Abweichung nicht für problematisch gehalten. Nach Angaben des Unternehmens prüften die Tests HTTP-Antwortcodes und die Leistung der Engine bei langen Kontexten, nicht jedoch die Modellausgaben und deren Kohärenz. Inzwischen prüft Cloudflare vor der Freigabe jeder Änderung an einer disaggregierten Bereitstellung direkt, ob die Größe des KV-Pools zur Kontextlänge passt.

Das zweite Problem war ein Fehler in SGLang bei der Verarbeitung überlanger Anfragen im disaggregierten Prefill- und Decode-Modus. Ein Prompt, der nicht in den Pool passte, wurde intern als abgelehnt markiert und durch einen Ein-Token-Platzhalter ersetzt. Das Prefill erzeugte jedoch weiterhin einen KV-Cache für diesen Platzhalter und signalisierte, dass die Übertragung abgeschlossen sei. Der Decode-Knoten generierte daraufhin eine Antwort und griff dabei auf veraltete Cache-Seiten mit Daten aus früheren Anfragen zu. Der Client erhielt eine HTTP-200-Antwort statt einer HTTP-400-Antwort.

Das SGLang-Team erklärte in einem eigenen, abgestimmten Beitrag, dass der Ablehnungspfad auf einem einzelnen Knoten stattdessen einen Fehler zurückgab. Das Problem trat daher nur beim disaggregierten Serving auf. Ein anderer Nutzer hatte den Fehler am 6. Juli 2026 als Issue #30233 an SGLang gemeldet. Cloudflare zufolge stieß das Unternehmen bei seinen Untersuchungen auf diesen Eintrag.

Reaktion auf den Vorfall und Behebung

Cloudflare begann am 9. September 2026 um 08:00 UTC mit der Überprüfung des Berichts. Um 13:22 erklärte das Unternehmen den Vorfall zum Sicherheitsvorfall, nachdem das Product-Security-Team die Offenlegung innerhalb von 25 Minuten anhand zweier unabhängiger Konten reproduziert hatte. Um 14:00 stellte Cloudflare GLM 5.3 auf privat, ermittelte um 14:35 die Ursache, brachte bis 14:52 alle Prefill-Knoten auf die korrigierte Konfiguration, setzte bis 19:04 die gesamte Bereitstellung mit einem von Cloudflare entwickelten Patch für die Engine neu auf und machte das Modell um 19:40 wieder öffentlich zugänglich. Auf der Cloudflare-Statusseite wurde der Beginn des Vorfalls bei Workers AI mit 10:25 Uhr EDT am 9. September 2026 angegeben, die Identifizierung mit 11:02 Uhr EDT und die Behebung mit 16:09 Uhr EDT.

Durch die Konfigurationskorrektur wurde die Einrichtung von GLM 5.2 übernommen. Dadurch stand genügend GPU-Speicher zur Verfügung, sodass der Prefill-KV-Pool nun etwa 2,04 Millionen Tokens fasst – ungefähr doppelt so viel wie das Kontextfenster mit 1.048.576 Tokens. Ein Prompt, der in das Kontextfenster passt, passt damit immer auch in den Pool. Der Patch für die Engine beendet Anfragen mit einer noch ausstehenden Ablehnung bereits an der Zulassungswarteschlange für die Disaggregation und gibt dabei den ursprünglichen Fehler zurück, bevor Bootstrap, Zuweisung oder KV-Cache-Übertragung stattfinden. Cloudflare überprüfte beide Änderungen anhand des Reproduktionsskripts des Forschers und eigener Tests mit Canary-Markierungen, bevor das Modell wiederhergestellt wurde.

Korrekturen im Upstream und laufende Arbeiten

Cloudflare schlug seine Korrektur als SGLang-Pull-Request #38704 vor. Die Maintainer führten daraufhin #38935 zusammen, das betroffene Anfragen nach dem von Cloudflare vorgeschlagenen Verfahren bereits bei der Zulassung zurückweist. Eine verwandte Korrektur, #36988, war am 6. September 2026 für einen ähnlichen Fehlerpfad zusammengeführt worden. Der Patch wurde mit SGLang v0.5.20 veröffentlicht; weitere Korrekturen folgten in v0.5.21, erschienen am 2. Oktober 2026, und v0.5.22, erschienen am 19. Oktober 2026. Cloudflare empfiehlt allen Betreibern von SGLang, auf v0.5.22 oder höher zu aktualisieren. Das SGLang-Team erklärt, dass v0.5.21 Mooncake- und NIXL-Bereitstellungen standardmäßig gegen alle Fehlerarten absichert, MORI-Bereitstellungen dafür einen Build in v0.5.22 benötigen und die Korrektur nicht auf frühere Release-Zweige zurückportiert wurde.

Das SGLang-Team berichtete, dass bei 21 Durchläufen auf zwei H100-GPUs die Durchsatzabweichungen mit den Schutzmaßnahmen innerhalb von ±2 % lagen und jedes 95-%-Konfidenzintervall den Wert null einschloss. Bei einem separaten Test mit 16 Durchläufen auf zwei H200-GPUs wurde der Aufwand für die standardmäßige Aktivierung der verzögerten KV-Freigabe mit −0,38 % gemessen. Das Konfidenzintervall von −2,12 % bis +1,36 % bezeichnete das Team als nicht signifikant. Cloudflare traf die SGLang-Maintainer am 10. September 2026 bei RadixArk, führte zwischen dem 11. und 19. September 2026 zusätzliche Härtungsmaßnahmen in allen produktiven SGLang-Bereitstellungen ein und brachte vom 16. September bis zum 12. Oktober 2026 Upstream-Änderungen zusammen, die die Zulassungsprüfung, Prüfsummen für jede Übertragung, die Beibehaltung von Abbruchbestätigungen und die standardmäßig aktivierte verzögerte KV-Freigabe abdeckten.

Für andere Betreiber, die SGLang im disaggregierten Modus ausführen, empfiehlt der Bericht von Cloudflare, den KV-Pool im Verhältnis zur Kontextlänge auf jedem Prefill- und Decode-Knoten nach jeder Änderung an Gewichten, Quantisierung, Parallelisierung oder Speicheranteil zu messen; auf einen Build mit beiden Korrekturen der Zulassungsprüfung zu aktualisieren; die verzögerte KV-Freigabe in beiden Rollen zu aktivieren; die Erkennung von Beschädigungen einzuschalten, sofern das Modell sie unterstützt; und Load-Balancer so zu konfigurieren, dass eine Client-Trennung eine Anfrage nicht mitten in der Übertragung abbricht.

Cloudflare zufolge hatte das Unternehmen zuvor einen Prototyp entwickelt, der jede physische KV-Seite markiert und die Zuordnung überprüft, bevor der Decode-Prozess den Cache ausliest. In Tests verursachte dieser Prototyp beim Durchsatz und bei der Tail-Latenz Einbußen von weniger als 1 %. Cloudflare testete ihn Mitte August 2026 mit GLM 5.2, deaktivierte ihn aber kurz darauf wegen Zuverlässigkeitsproblemen. Cloudflare arbeitet mit dem SGLang-Team an einer in die Engine integrierten Produktionsversion. Die Prüfsumme für jede Übertragung in Pull Request #39500 ist ein erster Schritt. Außerdem erklärte Cloudflare, das Unternehmen setze seine Erfahrung mit formalen Methoden ein, um die Sicherheit eines RDMA-basierten KV-Cache-Übertragungsprotokolls unter Verwendung von Mooncake in seiner produktiven SGLang-Bereitstellung zu modellieren und nachzuweisen.

Im Beitrag des SGLang-Teams werden die Cloudflare-Ingenieure Kevin Flansburg und Kastan Day für ihre Arbeit an den Korrekturen gewürdigt. Außerdem führt der Beitrag die koordinierte Offenlegung durch SGLang und Cloudflare am 26. Oktober 2026 als letzten Eintrag in der Zeitleiste der Offenlegung auf. Der eigene Bericht des Forschers, der nach Angaben des SGLang-Teams die Entdeckung und externe Validierung beschreiben wird, steht noch aus.