Cloudflare corrige une fuite de cache KV entre requêtes sur son modèle GLM-5.3

Cloudflare a publié le 26 octobre 2026 un rapport technique détaillé sur une fuite de cache KV entre requêtes qui a touché GLM-5.3 (@cf/zai-org/glm-5.3), l’un des modèles disponibles sur Workers AI. Pendant près de deux semaines, certaines requêtes à très long contexte ont pu recevoir des fragments de texte provenant de sessions d’autres clients. L’entreprise détaille la chronologie complète et les correctifs appliqués.

#Un décalage de configuration resté invisible aux tests

GLM-5.3 a été déployé le 27 août 2026 avec une fenêtre de contexte annoncée de 1 048 576 tokens, mais le pool de cache KV réservé au préremplissage ne couvrait que 681 280 tokens. Cloudflare savait que les deux chiffres ne correspondaient pas avant la mise en production, mais ses tests internes renvoyaient des réponses HTTP 200 valides, ce qui a masqué le problème.

#Un bug SGLang qui transforme un rejet en fuite

Le moteur d’inférence SGLang, utilisé en coulisses, marque normalement une requête trop longue comme rejetée et lui substitue un jeton de remplacement. En mode désagrégé, la file d’admission vérifiait seulement si la requête était terminée, pas si elle avait été rejetée. Le jeton était donc accepté : le préremplissage transférait une seule page de cache, tandis que le décodage en réservait huit, dont sept contenaient encore des données issues de requêtes précédentes.

Le serveur renvoyait un code HTTP 200, comme pour une réponse normale, alors que la requête aurait dû être rejetée avec un code 400.

#Chronologie de l’incident

Au total, Cloudflare dénombre 155 réponses affectées, sans preuve d’exploitation malveillante au-delà de ses propres tests et de ceux du chercheur. Le pool de cache a depuis été porté à environ 2,04 millions de tokens, soit le double de la fenêtre de contexte annoncée, pour que toute requête valide y tienne. La rapidité de la détection, 25 minutes entre la reproduction et la déclaration d’incident, doit beaucoup à une supervision outillée et un triage rodé des alertes, deux réflexes qui valent pour n’importe quelle infrastructure partagée entre clients.

#Ce que les opérateurs de SGLang en mode désagrégé doivent vérifier

Au-delà de Workers AI, l’alerte concerne toute équipe qui exploite SGLang en mode désagrégé pour son propre service d’inférence. Cloudflare recommande de comparer la taille du pool KV à la fenêtre de contexte annoncée, au démarrage comme après chaque changement de configuration. Même réflexe que celui déjà recommandé après la faille RCE du décodeur Brotli de Node.js début octobre : vérifier la configuration réelle en production, pas seulement sa documentation.

# Comparer le pool KV déclaré au démarrage avec la fenêtre de contexte du modèle
grep -i "kv_pool\|context_length" sglang_server.log | tail -n 20

# Mettre à jour vers une version corrigée (admission fix inclus)
pip install "sglang>=0.5.22"

# Activer les garde-fous recommandés en mode désagrégé
python -m sglang.launch_server \
  --disaggregation-mode decode \
  --disaggregation-enable-kv-checksum \
  --kv-canary

#Ce qu’il faut retenir

L’incident ne vient pas d’une injection ou d’un contournement actif, mais de la rencontre entre une configuration mal calibrée et un bug d’admission resté silencieux pendant des mois dans SGLang, un rappel que l’infrastructure d’inférence partagée est un maillon à part entière des architectures agentiques décrites par des standards comme la spécification MCP. Le correctif est en production depuis le 9 septembre 2026 ; le rapport du 26 octobre sert surtout à alerter les opérateurs de SGLang indépendants qui n’ont pas forcément suivi les correctifs amont.

Pour aller plus loin : le rapport complet de Cloudflare est disponible sur blog.cloudflare.com.