GLM-5.3 auf Workers AI gab Fremddaten aus

Vom 27.08. bis zum 09.09.2026 konnte das Modell GLM-5.3 auf Cloudflare Workers AI in seinen Antworten Text aus Anfragen anderer Kunden ausgeben. Das schreibt Cloudflare in einem Bericht vom 26.10.2026. Betroffen waren 155 Antworten, alle auf Prompts mit mehr als 681.280 Token. Gemeldet hat das der Sicherheitsforscher Gadi Evron von Knostic über das Bug-Bounty-Programm von Cloudflare.

Auf Workers AI ist der Fehler seit dem 09.09. behoben, laut Cloudflare war kein anderes Modell betroffen. Interessant ist der Fall für alle, die selbst Modelle mit der Open-Source-Inferenz-Engine SGLang betreiben. Denn die Hälfte der Ursache steckte dort.

Was passiert ist

Cloudflare betreibt GLM-5.3 mit getrenntem Prefill und Decode. Ein Pool von GPUs verarbeitet den Prompt und berechnet daraus den KV-Cache, also den Zwischenspeicher, auf den das Modell beim Antworten zugreift. Ein zweiter Pool erzeugt die Antwort. Der Cache wird per RDMA zwischen den Maschinen übertragen. Seine Speicherseiten werden zwischen Anfragen nicht gelöscht, sondern einfach überschrieben, was in Inferenz-Engines aus Performancegründen üblich ist.

Zwei Fehler kamen zusammen:

Konfiguration. Das Modell lief mit einem Kontextfenster von 1.048.576 Token, der KV-Cache auf den Prefill-GPUs fasste aber nur 681.280. Cloudflare kannte die Lücke vor dem Start, ging aber davon aus, dass SGLang zu lange Prompts mit einem Fehler ablehnt. Die Tests prüften nur Statuscodes und Tempo, nicht den Inhalt der Antworten.
SGLang. Zu lange Prompts hat SGLang tatsächlich abgelehnt, intern aber durch einen Platzhalter mit einem Token ersetzt. Im getrennten Betrieb lief diese abgelehnte Anfrage trotzdem durch. Prefill schrieb nur eine Speicherseite, Decode las alle reservierten Seiten. Die übrigen enthielten noch Reste früherer Anfragen anderer Nutzer. Der Client bekam keinen Fehler, sondern eine flüssige Antwort mit fremden Inhalten.

Den SGLang-Fehler hatte ein anderer Nutzer schon am 06.07.2026 als Issue gemeldet, allerdings als Ausgabe von Unsinn und nicht als Datenleck. Laut Cloudflare passen die betroffenen Anfragen zu normaler Nutzung mit langen Kontexten, Hinweise auf gezieltes Ausnutzen gab es nicht. Ob die betroffenen Kunden informiert wurden, steht nicht im Bericht.

Wer handeln muss

Betroffen sind SGLang-Installationen, die Prefill und Decode auf getrennten Servern betreiben und den KV-Cache per Mooncake, NIXL oder MORI übertragen. Ein einzelner Server ohne diesen Übertragungsweg ist laut dem Beitrag des SGLang-Teams nicht betroffen.

Das SGLang-Team beschreibt neben dem Fehler aus dem Vorfall eine ganze Klasse verwandter Probleme. Bricht eine Anfrage ab, während Prefill noch Daten überträgt, können diese späten Schreibvorgänge im Cache einer anderen Anfrage landen. Das Team nennt das "distributed use-after-free". Betroffen sind Standardkonfigurationen seit der Versionslinie 0.4 aus Anfang 2025.

Was zu tun ist:

Updaten. Cloudflare empfiehlt SGLang v0.5.22 vom 19.10.2026 oder neuer. Laut SGLang-Team schützt v0.5.21 Mooncake- und NIXL-Installationen standardmäßig, für MORI braucht es v0.5.22. Einzelne Korrekturen erscheinen erst mit v0.5.23. Ältere Versionszweige bekommen die Fixes nicht.
Speicher gegen Kontext prüfen. Die Größe des KV-Cache-Pools steht im Startlog. Liegt sie unter der eingestellten Kontextlänge, muss die Kontextlänge runter. Das gilt nach jeder Änderung an Gewichten, Quantisierung oder Parallelisierung neu.
Erkennung einschalten, wo möglich. --disaggregation-enable-kv-checksum lässt Decode eine Prüfsumme des übertragenen Caches vergleichen. Die Option ist wegen des Mehraufwands standardmäßig aus und deckt noch nicht jede Modellarchitektur ab.

Wer auf v0.5.19 oder v0.5.20 festhängt, findet im SGLang-Beitrag Umgebungsvariablen als Übergangslösung. Ein Update ersetzen sie laut Team nicht.

Wer GLM-5.3 aus den offenen Gewichten selbst betreibt und dafür SGLang mit getrenntem Prefill nutzt, sollte vor allem Punkt 2 ernst nehmen. Genau an dieser Stelle hat Cloudflare die Prüfung ausgelassen.