Cloudflare schließt KV-Cache-Leck zwischen Anfragen bei seinem GLM-5.3-Modell

Cloudflare hat am 26. Oktober 2026 einen ausführlichen technischen Bericht über ein KV-Cache-Leck zwischen Anfragen veröffentlicht, das GLM-5.3 (@cf/zai-org/glm-5.3) betraf, eines der auf Workers AI verfügbaren Modelle. Fast zwei Wochen lang konnten manche Anfragen mit sehr langem Kontext Textfragmente aus den Sitzungen anderer Kunden erhalten. Das Unternehmen legt die vollständige Chronologie und die angewendeten Korrekturen offen.

#Eine Konfigurationsabweichung, die Tests nicht auffiel

GLM-5.3 ging am 27. August 2026 mit einem angekündigten Kontextfenster von 1.048.576 Tokens live, doch der für das Prefill reservierte KV-Cache-Pool deckte nur 681.280 Tokens ab. Cloudflare wusste vor dem Start, dass die beiden Zahlen nicht übereinstimmten, aber die internen Tests lieferten gültige HTTP-200-Antworten, wodurch das Problem verborgen blieb.

#Ein SGLang-Fehler, der aus einer Ablehnung ein Leck macht

Die Inferenz-Engine SGLang markiert eine zu lange Anfrage normalerweise als abgelehnt und ersetzt sie durch ein Platzhalter-Token. Im disaggregierten Modus prüfte die Admission-Queue nur, ob eine Anfrage abgeschlossen war, nicht ob sie abgelehnt wurde. Das Platzhalter-Token wurde daher zugelassen: Das Prefill übertrug eine einzige Cache-Seite, während die Dekodierung acht reservierte, von denen sieben noch Daten aus früheren Anfragen enthielten.

Der Server antwortete mit HTTP 200, wie bei einer normalen Antwort, obwohl die Anfrage mit einem 400er-Code hätte abgelehnt werden müssen.

#Chronologie des Vorfalls

Insgesamt zählt Cloudflare 155 betroffene Antworten, ohne Hinweise auf eine gezielte Ausnutzung über die eigenen Tests und die des Forschers hinaus. Der Cache-Pool wurde seither auf rund 2,04 Millionen Tokens angehoben, das Doppelte des angekündigten Kontextfensters, damit jede gültige Anfrage hineinpasst. Dass nur 25 Minuten zwischen Reproduktion und Vorfallserklärung lagen, verdankt sich auch einer gut instrumentierten Überwachung und eingespielten Alarm-Triage, zwei Reflexen, die für jede zwischen Kunden geteilte Infrastruktur gelten.

#Was Betreiber von SGLang im disaggregierten Modus prüfen sollten

Über Workers AI hinaus betrifft die Warnung jedes Team, das SGLang im disaggregierten Modus für seinen eigenen Inferenzdienst betreibt. Cloudflare empfiehlt, die Größe des KV-Pools beim Start und nach jeder Konfigurationsänderung mit dem angekündigten Kontextfenster zu vergleichen. Derselbe Reflex, der bereits nach der RCE-Lücke im Brotli-Decoder von Node.js Anfang Oktober empfohlen wurde: die tatsächliche Produktionskonfiguration prüfen, nicht nur ihre Dokumentation.

# Beim Start deklarierten KV-Pool mit dem Kontextfenster des Modells vergleichen
grep -i "kv_pool\|context_length" sglang_server.log | tail -n 20

# Auf eine korrigierte Version aktualisieren (inklusive Admission-Fix)
pip install "sglang>=0.5.22"

# Empfohlene Schutzmaßnahmen im disaggregierten Modus aktivieren
python -m sglang.launch_server \
  --disaggregation-mode decode \
  --disaggregation-enable-kv-checksum \
  --kv-canary

#Was man sich merken sollte

Der Vorfall entstand nicht durch eine Injektion oder eine aktive Umgehung, sondern durch das Zusammentreffen einer falsch kalibrierten Konfiguration mit einem monatelang unbemerkten Admission-Fehler in SGLang, eine Erinnerung daran, dass gemeinsam genutzte Inferenz-Infrastruktur längst eine eigene Schicht agentischer Architekturen ist. Der Fix läuft bereits seit dem 9. September 2026 in Produktion; der Bericht vom 26. Oktober dient vor allem dazu, unabhängige SGLang-Betreiber zu warnen, die die Upstream-Patches womöglich nicht verfolgt haben.

Zum Weiterlesen: Der vollständige Bericht von Cloudflare ist verfügbar unter blog.cloudflare.com.