Cloudflare behebt Cross-Request-Datenleck im GLM-5.3-Inferenz-Engine

Cloudflare legte einen Sicherheitsvorfall auf seiner Workers-AI-Plattform offen, bei dem das Modell GLM-5.3 versehentlich Daten aus Anfragen anderer Nutzer zurückgab. Die Schwachstelle war vom 27. August bis zum 9. September 2026 aktiv, betraf 155 Antworten und wurde durch spezifische Prompts mit langem Kontext ausgelöst. Cloudflare hat die zugrunde liegende Inferenz-Engine inzwischen gepatcht und das Modell mit verbesserten Sicherheitsprüfungen wieder bereitgestellt.

Was passiert ist

Am 8. September 2026 meldete der Sicherheitsforscher Gadi Evron, dass das Modell @cf/zai-org/glm-5.3 auf Workers AI Sitzungsdaten lecke. Cloudflare reproduzierte das Problem am folgenden Morgen und nahm das Modell innerhalb von 40 Minuten offline. Die Untersuchung ergab, dass zwischen dem 27. August und dem 9. September eine kleine Anzahl von Kunden Antworten erhielt, die Text aus Anfragen anderer Kunden an dasselbe Modell enthielt, die kurz vor ihrer eigenen Anfrage gestellt worden waren. Alle 155 betroffenen Antworten wurden aus Prompts erzeugt, die 681.280 Tokens überschritten. Cloudflare fand keine Hinweise auf eine vorsätzliche Ausnutzung und stellte fest, dass die Anfragemuster gewöhnlicher Nutzung mit langem Kontext entsprachen, nicht gezielten Angriffen.

Die Ursache war eine Kombination aus einem Konfigurationsfehler und einem Bug in SGLang, der Open-Source-Inferenz-Engine, die den Dienst betreibt. Cloudflare hatte GLM-5.3 mit einem Kontextfenster von 1.048.576 Tokens bereitgestellt, aber der Key-Value-(KV)-Cache-Pool auf den Prefill-GPUs konnte nur 681.280 Tokens speichern. Obwohl das Team sich dieser Diskrepanz bewusst war, ging man davon aus, dass die Engine einen Fehler zurückgeben würde, wenn Prompts nicht passten. Stattdessen versuchte die Engine, die Anfrage über einen fehlerhaften Ablehnungspfad zu verarbeiten, was zur Offenlegung führte. Keine anderen Modelle auf Workers AI waren betroffen, da ihre KV-Pools größer als ihre jeweiligen Kontextlängen waren.

Wie es funktioniert

Workers AI stellt GLM-5.3 unter Verwendung einer disaggregierten Architektur bereit, bei der Prefill-GPUs Prompts verarbeiten und KV-Caches generieren, die dann über Remote Direct Memory Access (RDMA) an Decode-GPUs zur Antwortgenerierung übertragen werden. Der KV-Cache wird in einem gemeinsamen Pool fester Seiten im GPU-Speicher gespeichert. Um hohe Leistung aufrechtzuerhalten, werden diese Seiten zwischen Anfragen nicht gelöscht; die Engine verlässt sich auf eine strenge Eigentumsverfolgung, um sicherzustellen, dass eine neue Anfrage alle vorherigen Daten in ihren zugewiesenen Seiten überschreibt.

Wenn ein Prompt die Größe des KV-Pools überschritt, markierte der SGLang-Scheduler die Anfrage als abgelehnt, ersetzte sie jedoch durch einen Ein-Token-Platzhalter, damit sie durch die Batch-Maschinerie geleitet werden konnte. In einer Single-Node-Konfiguration hätte dies zu einem Fehler geführt. In der disaggregierten Konfiguration prüften die Zulassungswarteschlangen jedoch, ob eine Anfrage "finished" (fertig) war, anstatt "rejected" (abgelehnt). Da die abgelehnte Anfrage nicht als fertig markiert war, wurde sie auf den Prefill-Node zugelassen. Der Prefill-Node generierte einen Cache für den Ein-Token-Platzhalter und übertrug ihn an den Decode-Node. Der Decode-Node, der eine vollständige Übertragung erwartete, behielt die restlichen reservierten Seiten, die noch veraltete Daten früherer Benutzer enthielten. Folglich enthielt die endgültige Antwort kohärenten Text, der aus dem Platzhalter generiert wurde, gemischt mit geleakten Daten aus den veralteten Cache-Seiten.

Wichtige Details

• Betroffenes Modell: Nur @cf/zai-org/glm-5.3 war betroffen; alle anderen Workers-AI-Modelle blieben sicher.
• Expositionszeitraum: Die Schwachstelle bestand vom 27. August 2026 bis zur Offline-Nahme des Modells am 9. September 2026.
• Auswirkungsbereich: Genau 155 Antworten waren betroffen, alle stammten aus Prompts mit mehr als 681.280 Tokens.
• Ursache: Eine Diskrepanz zwischen dem Kontextfenster von 1.048.576 Tokens und dem KV-Cache-Pool von 681.280 Tokens, kombiniert mit einem Bug in der Handlung abgelehnter Anfragen durch SGLang im disaggregierten Modus.
• Abhilfe: Cloudflare erhöhte die Größe des KV-Pools auf ungefähr 2,04 Millionen Tokens und patchte SGLang, damit abgelehnte Anfragen vor der KV-Übertragung korrekt abgebrochen werden.
• Upstream-Fixes: Die Maintainer von SGLang haben mehrere Patches zusammengeführt, darunter PR #38704 und #38935, und die Versionen v0.5.21 und v0.5.22 veröffentlicht, um das Problem für alle Nutzer zu beheben.

Warum es wichtig ist

Dieser Vorfall unterstreicht die Fragilität der Speichersicherheit in Hochleistungs-LLM-Inferenz-Engines. Wenn Anbieter größere Kontextfenster und schnelleren Durchsatz anstreben, setzen sie oft komplexe Architekturen wie disaggregiertes Prefill und Decode ein. Diese Systeme verlassen sich auf präzises State-Management über mehrere Nodes hinweg. Wenn Konfigurationswerte wie Kontextlänge und Speicherpoolgröße nicht strikt erzwungen werden, können Edge Cases zu schwerwiegenden Sicherheitslücken führen. Für Engineering-Teams, die auf diesen Plattformen aufbauen, betont dies die Bedeutung des Verständnisses, dass Leistungsoptimierungen wie die Wiederverwendung nicht gelöschter Speicher erhebliche Verantwortung für den Infrastruktur-Anbieter mit sich bringen.

Für Entwickler, die Workers AI oder ähnliche Dienste nutzen, dient dieses Ereignis als Erinnerung daran, dass Mandantenisolation nicht nur ein Netzwerkproblem ist, sondern auch eine Herausforderung beim Speichermanagement innerhalb der Inferenz-Engine selbst. Während Cloudflares schnelle Reaktion die Exposition begrenzte, zeigt die Tatsache, dass 155 Nutzer geleakte Daten erhielten, dass selbst kurze Zeitfenster der Verwundbarkeit greifbare Konsequenzen haben können. Es demonstriert auch den Wert koordinierter Offenlegung und Open-Source-Kollaboration, da die von Cloudflare entwickelten Fixes upstream zusammengeführt wurden, um der breiteren SGLang-Community zugutezukommen.

Was Sie tun können

• SGLang aktualisieren: Wenn Sie Ihre eigene Inferenz-Infrastruktur mit SGLang betreiben, aktualisieren Sie sofort auf Version v0.5.22 oder neuer, um die neuesten Sicherheitspatches zu integrieren.
• Konfigurationen validieren: Stellen Sie sicher, dass die Größe Ihres KV-Cache-Pools für jedes bereitgestellte Modell strikt größer ist als die maximale Kontextlänge. Verlassen Sie sich nicht darauf, dass die Engine Inkonsistenzen elegant handhabt.
• Auf Anomalien überwachen: Implementieren Sie Logging und Monitoring für Antwortzeiten und Token-Zahlen. Antworten, die unerwartet schnell für lange Prompts eintreffen, können auf abgeschnittene Verarbeitung oder Cache-Fehler hinweisen.
• Disaggregierte Setups überprüfen: Wenn Sie disaggregierte Prefill/Decode-Architekturen verwenden, stellen Sie sicher, dass Ablehnungspfade korrekt über Nodes hinweg gehandhabt werden und dass abgelehnte Anfragen nicht zur KV-Übertragung fortschreiten.
• Upstream-Issues prüfen: Überprüfen Sie regelmäßig die Issue-Tracker der Inferenz-Engines, von denen Sie abhängen, wie z. B. SGLang, auf bekannte Bugs bezüglich Speichersicherheit und Race Conditions.
• Langkontext-Nutzung auditieren: Wenn Ihre Anwendung sehr lange Kontextfenster nutzt, führen Sie spezifische Integrationstests durch, die die Kohärenz der Ausgabe und die Isolation unter Last validieren, anstatt nur HTTP-Statuscodes zu prüfen.