Workers AI: GLM-5.3 lieferte fremde Kundendaten durch SGLang-Fehler
Cloudflare legt offen, dass GLM-5.3 auf Workers AI zwischen 27. August und 9. September 2026 in 155 Antworten Daten anderer Kunden ausgab. Ursache war ein Fehler in SGLang im disaggregierten Prefill/Decode-Modus. Betreiber eigener SGLang-Cluster sollten auf Version 0.5.22 aktualisieren.
Cloudflare hat einen Fehler in der Mandantentrennung seiner KI-Plattform Workers AI offengelegt: Zwischen dem 27. August und dem 9. September 2026 enthielten 155 Antworten des Modells GLM-5.3 (@cf/zai-org/glm-5.3) Daten aus Anfragen anderer Kunden. Betroffen waren ausschließlich Prompts mit mehr als 681.280 Tokens. Ursache war eine Kombination aus einer Fehlkonfiguration bei Cloudflare und einem Fehler in der Open-Source-Inferenz-Engine SGLang. Cloudflare und das SGLang-Team haben am 26. Oktober 2026 koordiniert berichtet.
Für Workers-AI-Kunden ist der Vorfall behoben, andere Modelle waren laut Cloudflare nicht betroffen. Relevant ist die Meldung vor allem für Teams, die SGLang selbst im disaggregierten Prefill/Decode-Modus betreiben. Sie sollten zeitnah auf Version 0.5.22 oder neuer aktualisieren und ihre Konfiguration prüfen. Einzelknoten-Installationen ohne diese Aufteilung lieferten in derselben Situation laut SGLang korrekt einen Fehler.
Was ist passiert?
Gemeldet hat das Problem der Sicherheitsforscher Gadi Evron von Knostic am 8. September über das HackerOne-Programm von Cloudflare. Sehr lange Prompts lieferten Text aus fremden Sitzungen zurück. Cloudflare reproduzierte den Fehler am Folgetag, nahm das Modell offline und stellte es am Abend mit korrigierter Konfiguration und gepatchter Engine wieder bereit.
GLM-5.3 lief mit einem Kontextfenster von 1.048.576 Tokens, der KV-Cache auf den Prefill-GPUs fasste aber nur 681.280 Tokens. Cloudflare kannte die Abweichung, ging aber davon aus, dass die Engine zu lange Anfragen sauber ablehnt. Tatsächlich markierte SGLang solche Anfragen intern als abgelehnt und ersetzte den Prompt durch einen Platzhalter mit einem Token. Im disaggregierten Modus lief die Anfrage trotzdem weiter: Der Decode-Knoten reservierte Speicherseiten für den langen Prompt, erhielt aber nur eine beschriebene Seite. Die übrigen Seiten enthielten noch Reste früherer Anfragen anderer Nutzer. Der Client bekam HTTP 200 statt HTTP 400 und eine zusammenhängende Antwort mit fremden Inhalten. Seiten im KV-Cache werden zwischen Anfragen nicht genullt, die Engine muss die Zuordnung selbst verwalten.
Nach Angaben von Cloudflare passen die betroffenen Anfragen zu normaler Nutzung mit langem Kontext. Hinweise auf gezielte Ausnutzung fand das Unternehmen nicht. Der zugrunde liegende SGLang-Fehler war bereits im Juli als Issue gemeldet worden.
Wer ist betroffen?
Direkt betroffen waren Kunden, die GLM-5.3 auf Workers AI im genannten Zeitraum mit sehr langen Prompts genutzt haben. Indirekt betroffen sind alle Betreiber von SGLang mit Prefill/Decode-Disaggregation und KV-Transfer über Mooncake, NIXL oder MORI, bei denen der KV-Pool kleiner als die beworbene Kontextlänge ist. SGLang beschreibt zusätzlich eine verwandte Fehlerklasse: Bricht eine Anfrage während des Transfers ab, können späte RDMA-Schreibzugriffe den Cache einer anderen Anfrage überschreiben. Wer Modelle lokal per Ollama oder auf einem einzelnen Knoten betreibt, ist von diesem konkreten Fehlerpfad nicht betroffen. Andere Engines wie vLLM nennen die Quellen nicht.
Wie kritisch ist das?
Für Workers AI ist der Fall abgeschlossen. Für eigene Multi-Tenant-Inferenz mit SGLang ist die Lage ernst, weil der Fehler still auftritt: Es gibt keine Fehlermeldung, nur fremde Daten in einer scheinbar normalen Antwort. Wer solche Cluster für mehrere Kunden oder Abteilungen betreibt, sollte das Update nicht bis zum nächsten regulären Fenster schieben.
Was sollten Admins jetzt tun?
- Inventar prüfen: Welche SGLang-Version läuft, ist Prefill/Decode-Disaggregation aktiv und welcher KV-Transfer-Backend wird genutzt?
- Auf SGLang 0.5.22 oder neuer aktualisieren. Diese Version enthält die Korrekturen #36988 und #38935, die abgelehnte Anfragen vor der Übergabe stoppen.
- Die beim Start geloggte KV-Pool-Größe auf jedem Prefill- und Decode-Knoten mit der konfigurierten Kontextlänge vergleichen, nach jeder Änderung an Gewichten, Quantisierung oder Parallelisierung. Ist der Pool kleiner, die Kontextlänge senken.
- Verzögerte KV-Freigabe auf beiden Rollen aktiv lassen und, wo das Modell es unterstützt,
--disaggregation-enable-kv-checksumsowie--kv-canaryeinschalten. - Load Balancer so konfigurieren, dass Client-Abbrüche keine Transfers mitten im Lauf abbrechen.
- Bei langen Kontexten nicht nur HTTP-Statuscodes testen, sondern auch die Antwortinhalte mit Markierungstexten prüfen.
Einordnung für Unternehmen
Der Vorfall zeigt ein Risiko, das bei gemeinsam genutzter KI-Infrastruktur leicht übersehen wird: Mandantentrennung hängt nicht nur an Konten und API-Schlüsseln, sondern auch an der Speicherverwaltung der Inferenz-Engine. Cloudflare räumt ein, vor dem Start nur Statuscodes und Leistung geprüft zu haben, nicht die Antwortinhalte. Unternehmen, die KI-Dienste für mehrere Mandanten bereitstellen, sollten Kontextlängen und Speicherpools daher genauso streng prüfen wie Netzwerkgrenzen. Für Nutzer externer Plattformen bleibt die Frage, welche Daten in lange Prompts gehören.
