Vertiefende Analyse · Etwa 5 Min. Lesezeit
Cloudflare erklärt den GLM-5.3-Cachevorfall und warum erfolgreiche Antworten keine Isolation belegen
Die Veröffentlichung vom 26. Oktober trennt den Vorfall im August und September von Korrekturen und noch offener Integritätsarbeit.
- Hier veröffentlicht
- Datum der Quelle
- Quelle geprüft
Cloudflare veröffentlichte am 26. Oktober einen Bericht über anfrageübergreifende Datenoffenlegung beim GLM-5.3-Betrieb auf Workers AI. Als Ursache nennt das Unternehmen eine Kapazitätsabweichung zusammen mit einem SGLang-Fehler bei der Ablehnung. Der Dienst wurde am 9. September repariert; der Bericht beschreibt weder einen neuen Ausfall noch einen nachgewiesenen Fehler aller Modellbereitstellungen.
Nachrichten anhören
Diesen Artikel vorlesen oder mit den Nachrichten fortfahren.
Vorlesen wird vorbereitet…
Gerätestimme
Browser oder Gerät verarbeiten die Sprache. AISubHub sendet den Text nicht an eine Audio-API. Stimmen und Wiedergabe bei gesperrtem Bildschirm hängen vom Gerät ab.
Beim Fortsetzen kann sich ein kurzer Satzteil wiederholen.
Auf einen Blick
- Cloudflare meldet 155 betroffene Antworten zwischen dem 27. August und 9. September, alle bei Prompts über 681 280 Tokens. Gemeint sind Antworten, nicht Kunden.
- Dem angekündigten Kontext von 1 048 576 Tokens stand ein Prefill-Pool von 681 280 gegenüber. Nach der Korrektur fasst er etwa 2,04 Millionen; auch die Ablehnung im Engine-Code wurde repariert.
- Für getrennte Prefill-/Decode-Betreiber empfiehlt Cloudflare SGLang v0.5.22 oder neuer. Die Erkennung hängt von der Architektur ab; weitere Integritätsarbeiten sind keine allgemeine Garantie.
Offenlegung und Vorfall haben unterschiedliche Daten
Cloudflare datiert die Datenexposition auf den Zeitraum vom Workers-AI-Start am 27. August bis zum 9. September. Gadi Evron von Knostic meldete das Problem am 8. September. Am Folgetag erklärte Cloudflare um 13:22 UTC einen Vorfall, sperrte den öffentlichen Zugriff um 14:00 und stellte ihn nach Änderungen und Prüfung um 19:40 wieder her. Der 26. Oktober ist das koordinierte Veröffentlichungsdatum.
Das Unternehmen identifiziert 155 Antworten mit Inhalten aus kurz zuvor eingegangenen Anfragen anderer Kunden an dasselbe Modell. Ohne eigene und Forscher-Tests passten Zeitpunkte und Mengen nach seiner Einschätzung zur normalen Nutzung langer Kontexte; Hinweise auf gezielte Ausnutzung fand es nicht. Das beweist nicht, dass es nie Missbrauch gab. Andere Workers-AI-Modelle seien nicht betroffen gewesen.
Das Kontextfenster war größer als der physische Pool
Prefill-GPUs verarbeiteten Prompts und übertrugen den Schlüssel-Wert-Cache über Mooncake und RDMA an Decode-GPUs. SGLang berechnete die Poolgröße aus dem nach dem Laden der Gewichte verbleibenden Speicher. Die Kontextgrenze war separat eingestellt. So konnte ein Kontext von 1 048 576 Tokens mit einem Pool für nur 681 280 Tokens zusammenfallen.
Cloudflare räumt ein, die Abweichung vor dem Start gekannt zu haben. Erfolgreiche Langkontexttests ließen jedoch eine sichere Ablehnung übergroßer Anfragen erwarten. Der Bericht benennt die Lücke: HTTP-Status und Leistung wurden geprüft, die Ausgabe nicht ausreichend validiert. Beschrieben wird das Zusammenspiel von Betriebskonfiguration und Engine; Belege für eine Hintertür in Modellgewichten liefert der Bericht nicht.
Eine vorgemerkte Ablehnung galt weiter als aktive Anfrage
Der Scheduler merkte eine zu große Anfrage zur Ablehnung vor und ersetzte den Prompt durch einen Ein-Token-Platzhalter. Im getrennten Betrieb prüfte die Zulassung jedoch, ob die Anfrage beendet war, nicht ob sie abgelehnt wurde. Der vorgemerkte Fehler erfüllte diese Bedingung nicht. Beide Seiten akzeptierten daher eine Anfrage, die mit einem Fehler hätte enden müssen.
Die Grafik veranschaulicht acht reservierte Seiten: Eine wurde neu beschrieben, sieben konnten alte Inhalte enthalten. Das sind Erklärungszahlen, keine gemessenen Vorfallmengen. Der Client konnte HTTP 200, plausible Tokenzahlen und zusammenhängenden Text erhalten, obwohl frühere Anfrageinhalte enthalten waren. Eine erfolgreiche Übermittlung belegte keine korrekte Isolation.
Die unmittelbare Korrektur hatte zwei Ebenen
Laut Cloudflare fasst der korrigierte Prefill-Pool ungefähr 2,04 Millionen Tokens und übersteigt damit den Kontext von 1 048 576. Außerdem beendet die Engine vorgemerkte Ablehnungen schon bei der Zulassung, vor Speicherzuteilung und Cachetransfer. Beide Änderungen seien vor der Wiederfreigabe geprüft worden. Nur den Pool zu vergrößern wäre eine fragile Abhängigkeit von künftigen Speichereinstellungen.
Die Tabelle unterscheidet eine erste Korrektur in v0.5.20, frühere Ablehnung in v0.5.21 und weitere Härtung bis v0.5.22. Für getrennte Betreiber empfiehlt Cloudflare v0.5.22 oder neuer beziehungsweise passende Rückportierungen. Das betrifft den beschriebenen Betriebsmodus und die Korrekturen, nicht einen Leistungsvergleich oder die Garantie, dass eine Versionsnummer jede Bereitstellung sicher macht.
Laufende Schreibvorgänge verlängern die Seitenverantwortung
Der Bericht erläutert außerdem eine verwandte Fehlerklasse: Ein Abbruch kann bereits abgesandte RDMA-Schreibvorgänge nicht zurückholen. Werden Zielseiten zu früh neu vergeben, können verspätete Schreibzugriffe eine andere Anfrage beschädigen. Anders als dieses zeitabhängige Rennen nahm die abgelehnte Anfrage hier deterministisch den falschen Übergabepfad. Beide Fälle verlangen Eigentumsverfolgung bis zum Ende aller beteiligten Operationen.
Cloudflare beschreibt verzögerte Freigabe auf beiden Rollen, begrenzte Mooncake-Batches, geänderte Verbindungsabbruchbehandlung und Bereitstellungsprüfungen. Die realen Pools sollten nach Änderungen an Gewichten, Quantisierung oder Parallelität gemessen werden. Prüfsummen und KV Canary unterstützen noch nicht jede Architektur. Ein eingeschalteter Parameter belegt deshalb nicht, dass jede Anfrage tatsächlich geprüft wird.
Langfristige Integrität ist noch keine abgeschlossene Zusage
Cloudflare testete im August einen Seitenmarkierungsprototyp auf GLM-5.2. Gemeldet werden weniger als 1% Aufwand bei Durchsatz und Tail-Latenz, doch Zuverlässigkeitsprobleme führten kurz danach zur Deaktivierung. Die Zahl beschreibt einen begrenzten Versuch, keinen aktiven allgemeinen Schutz oder universellen Aufwand. Das Nullsetzen bei Seitenfreigabe steht weiterhin als Entwurf im Bericht.
Eine Transferprüfsumme kontrolliert die Übergabe; Eigentumsprüfungen würden auch spätere Lesezugriffe erfassen. Cloudflare plant zudem formale Modelle des verteilten Protokolls und räumt Grenzen möglicher Beweise ein. AISubHub-Analyse: Isolation, Ablehnung und Lebensdauer brauchen getrennte Prüfungen. Ausgerollte Schutzmaßnahmen, Prototypen und zukünftige Absicherung müssen klar auseinandergehalten werden.
Warum es wichtig ist
AISubHub-Analyse: Mandantenisolation benötigt eigene Abnahmekriterien. HTTP-Status, Tokenzählung und Geschwindigkeit können korrekt wirken, obwohl Speicherzuordnung fehlschlägt. Konfigurations- und Fehlerpfadtests beantworten deshalb andere Fragen als ein Leistungsbenchmark.
Grenzen und Verfügbarkeit
Umfang, Behebung und fehlende Hinweise auf absichtliche Ausnutzung stammen aus Cloudflares Darstellung. AISubHub hat weder Dienst noch Patches unabhängig geprüft. Der Bericht beweist weder eine Betroffenheit aller GLM-Bereitstellungen noch die Immunität jeder SGLang-Konfiguration gegen Cache-Lebensdauerfehler.
Quellen und Belege
Datum der Quelle: · Quelle geprüft:
KI-gestützte redaktionelle Beiträge, anhand der genannten Primärquellen geprüft. Anbieterangaben werden zugeordnet; eine Aufnahme ist keine Empfehlung.