Cloudflare legt einen Datenabfluss zwischen Anfragen bei einem gehosteten GLM-5.3-Modell offen

Cloudflare legt einen Datenabfluss zwischen Anfragen bei einem gehosteten GLM-5.3-Modell offen

Am 26. Oktober veröffentlichte Cloudflare einen Bericht nach dem Vorfall zu einem Mandanten-Isolationsfehler in seinem Dienst Workers AI. Der Sicherheitsforscher Gadi Evron von Knostic hatte am 8. September gemeldet, dass sehr lange Eingaben an das Modell GLM-5.3 (`@cf/zai-org/glm-5.3`) manchmal Text aus Sitzungen anderer Kunden zurückgaben. Laut Cloudflare begann die Offenlegung mit dem Start des Modells am 27. August; das Unternehmen nahm es am 9. September vom Netz und stellte es am selben Tag wieder her. Andere Workers-AI-Modelle seien nicht betroffen gewesen. Der Bericht trägt das Datum 26. Oktober, weil er mit einem Beitrag von SGLang abgestimmt wurde, der beteiligten Open-Source-Inferenz-Engine. Der Vorfall selbst liegt etwa sieben Wochen zurück. Diese Ausgabe vom 27. Oktober behandelt die Offenlegung, keinen neuen Angriff.

Cloudflare nennt eine Zahl: 155 Antworten waren betroffen, alle auf Eingaben mit mehr als 681.280 Token. Ein Token ist hier eine Texteinheit, die das Modell liest, und keine Kryptowährung. Nach Abzug der eigenen Tests und der Tests des Forschers passen die übrigen Anfragen nach Zeitpunkt und Menge laut Cloudflare zu gewöhnlicher Nutzung mit langem Kontext. Hinweise auf gezielte Ausnutzung habe man nicht gefunden. Das ist die eigene Feststellung des Unternehmens. Der Beitrag nennt weder die Zahl der betroffenen Kunden noch den Inhalt des abgeflossenen Textes.

Zwei Fehler kamen zusammen

Der erste Fehler war eine Konfigurationslücke. Cloudflare setzte das Modell mit einem Kontextfenster von 1.048.576 Token ein, doch der GPU-Speicherpool für den Aufmerksamkeits-Cache (KV-Cache) auf den Prefill-GPUs fasste nur 681.280 Token. Das Unternehmen sagt, es habe die Differenz vor dem Start gekannt und erwartet, dass die Engine bei jeder nicht passenden Eingabe einen Fehler zurückgibt. Die Tests mit langem Kontext lieferten erfolgreiche Antworten, also sah das Team darin kein Problem. Heute räumt es ein, dass diese Tests nur HTTP-Statuscodes und Geschwindigkeit prüften, nicht aber, ob die Ausgabe sinnvoll war.

Der zweite Fehler war ein Bug in SGLang, wenn Prefill und Decode auf getrennten GPU-Pools laufen. Eine für den Pool zu lange Eingabe wurde als abgelehnt markiert und durch einen Ersatz aus einem einzigen Token ausgetauscht, die Anfrage selbst wurde aber nicht gestoppt. Der Prefill schrieb eine einzige Cache-Seite und meldete dem Decode-Knoten, die Übertragung sei abgeschlossen. Im Beispiel der Abbildung von Cloudflare reserviert der Decode-Knoten acht Seiten für die echte Eingabe und geht davon aus, alle acht seien frisch. Sieben enthalten noch Daten früherer Anfragen, sodass das Modell antwortete, während es die Reste anderer Nutzer las. Der Client erhielt eine normale Erfolgsantwort und keinen Fehler. Cloudflare weist darauf hin, dass Cache-Seiten zwischen Anfragen nicht auf null gesetzt werden. Engines nehmen das üblicherweise der Geschwindigkeit wegen in Kauf, wodurch die Engine selbst verfolgen muss, wem jede Seite gehört.

Was Cloudflare geändert hat

Der Zeitablauf laut Bericht: Der Vorfall wurde am 9. September um 13:22 UTC ausgerufen. Um 14:00 Uhr wurde das Modell auf privat gestellt, um 14:35 Uhr war die Ursache gefunden, und um 19:40 Uhr kehrte das Modell mit korrigierter Konfiguration und gepatchter Engine in den öffentlichen Betrieb zurück. Der Prefill-Pool fasst jetzt etwa 2,04 Millionen Token, ungefähr das Doppelte des Kontextfensters, sodass eine gültige Eingabe immer hineinpasst. Zudem patchte Cloudflare die Engine so, dass eine abgelehnte Anfrage beendet wird, bevor eine Cache-Übertragung beginnt. SGLang lieferte verwandte Korrekturen in den Versionen v0.5.20 bis v0.5.22, und Cloudflare rät allen Betreibern von getrenntem SGLang zu v0.5.22 oder neuer. Genannt werden außerdem weitere Härtungen: verzögerte Freigabe von Cache-Seiten, begrenzte Übertragungsstapel und eine Prüfung vor dem Einsatz, die die Poolgröße mit der Kontextlänge vergleicht.

Was Leser daraus mitnehmen können

Wer gehostete Inferenz einkauft, nimmt eine enge, aber praktische Lehre mit. Dem Bericht zufolge hatten die Anfragen, die fremde Daten empfingen, Eingaben mit mehr als 681.280 Token. Wie lang die Anfragen der anderen Kunden waren, deren Daten abflossen, steht dort nicht. Dennoch kann ein Isolationsfehler 13 Tage lang ohne jede Fehlermeldung unbemerkt bleiben, wie es hier der Fall war. Teams, die eigene Engines betreiben, sollten die Cache-Kapazität mit der beworbenen Kontextlänge abgleichen, den Inhalt der Ausgaben testen statt nur Statuscodes und einen klaren Meldeweg für externe Forscher bereithalten. Cloudflares Darstellung ist ein Bericht des Anbieters über sich selbst. Der Beitrag enthält keine unabhängige Prüfung seiner Zahlen und beziffert die Folgen für Kunden nicht.