Cloudflare: 155 GLM-5.3-Antworten enthielten Daten fremder Anfragen
Victoria Shinder2 Min. LesezeitCloudflare hat eine koordinierte Offenlegung zu einem Fehler bei der Mandantentrennung im Modell GLM-5.3 auf Workers AI veröffentlicht. Zwischen dem 27. August und dem 9. September enthielten 155 Antworten Daten aus Anfragen anderer Kunden, die kurz zuvor an dasselbe Modell gingen. Betroffen waren ausschließlich Antworten auf Eingaben mit mehr als 681.280 Token. Gemeldet hatte es am 8. September der Forscher Gadi Evron von Knostic über HackerOne; Cloudflare reproduzierte den Fehler am nächsten Morgen, nahm das Modell 40 Minuten nach Ausrufen des Vorfalls vom Netz und stellte es am selben Tag wieder bereit. Andere Workers-AI-Modelle seien nicht betroffen, Hinweise auf gezielte Ausnutzung gebe es nicht.
Zwei Probleme überlagerten sich. Das Modell lief mit einem Kontextfenster von 1.048.576 Token, der KV-Cache-Pool auf den Prefill-GPUs fasste aber nur 681.280 Token — eine bekannte Diskrepanz, bei der Cloudflare eine saubere Ablehnung erwartete. Stattdessen wurde in SGLangs getrenntem Prefill/Decode-Modus eine zu lange Eingabe als abgelehnt markiert und durch einen Ein-Token-Platzhalter ersetzt, die Anfrage aber nicht abgebrochen. Prefill berechnete den Cache für den Platzhalter und meldete dem Decode-Knoten die Übertragung als abgeschlossen; Decode erzeugte daraufhin eine Antwort über Cache-Seiten, die noch Daten früherer Anfragen enthielten. KV-Seiten werden zwischen Anfragen nicht genullt.
Die Korrekturen: Der Pool fasst jetzt rund 2,04 Millionen Token, etwa das Doppelte der Kontextlänge, und die Engine wurde so gepatcht, dass eine Anfrage mit anhängiger Ablehnung vor jeder Zuteilung oder Übertragung mit ihrem Fehler beendet wird. Cloudflare reichte das upstream als SGLang #38704 ein; die Maintainer übernahmen zudem #38935.
Was das bedeutet
Die Ursache sind zwei Zahlen, die niemand zur Übereinstimmung zwang: Die beworbene Kontextlänge ist Konfiguration, die Poolgröße ergibt sich aus dem GPU-Speicher, der nach dem Laden der Gewichte übrig bleibt. Wer einen getrennten Inferenz-Stack betreibt, sollte beides prüfen — und einen Status 200 mit gestreamter Antwort nicht als Beweis lesen, dass eine lange Eingabe tatsächlich verarbeitet wurde.