Le 8 septembre 2026, Cloudflare a publié un rapport détaillant une fuite de données entre requêtes sur le modèle d’IA GLM‑5.3, hébergé via Workers AI. Entre le 27 août et le 9 septembre, 155 réponses contenant plus de 681 280 tokens ont exposé des fragments de prompts d’autres clients. Aucun indice d’exploitation intentionnelle n’a été détecté, mais la situation a mis en lumière une combinaison de mauvaise configuration et de bug dans le moteur d’inférence SGLang.

Chronologie de l’incident

Le problème a été signalé par le chercheur en sécurité Gadi Evron (Knostic) le 8 septembre. Cloudflare a reproduit le défaut le lendemain, a mis le modèle hors ligne en moins de 40 minutes, puis a appliqué une configuration corrigée et un correctif du moteur avant de réactiver le service le même jour. La restauration a eu lieu le 9 septembre, après validation avec le script de reproduction du chercheur et des tests canari.

Architecture de Workers AI et gestion du cache KV

Workers AI exécute GLM‑5.3 sur une architecture disaggregée : des GPU de pré‑remplissage (prefill) génèrent le cache KV du prompt, puis le transmettent via RDMA (Mooncake) à des GPU de décodage qui produisent la réponse. Le cache KV est un pool de pages mémoire partagées, alloué à chaque requête sans remise à zéro entre les sessions. Cette approche maximise les performances mais impose au moteur le suivi strict de la propriété des pages, tant au sein d’un nœud qu’entre les nœuds pré‑remplissage et décodage.

KV pool size: 681280 tokens

Le pool est dimensionné à l’initialisation en fonction de la mémoire GPU disponible, indépendamment de la longueur de contexte annoncée (1 048 576 tokens pour GLM‑5.3). Aucun mécanisme automatique ne garantit l’alignement de ces deux valeurs.

Origine technique de la fuite

Deux facteurs ont conduit à la contamination du cache. D’abord, la configuration initiale réservait un pool de 681 280 tokens, insuffisant pour la fenêtre de contexte de 1 048 576 tokens. Lorsqu’un prompt dépassait la capacité du pool, SGLang le marquait comme rejeté et le remplaçait par un placeholder d’un token, mais continuait à générer le cache KV pour ce placeholder et le transmettait au nœud de décodage. Ce dernier, recevant un message « transfer complete », supposait que le cache complet avait été écrasé, alors que la majeure partie du cache précédent restait intacte. Le décodage a alors produit une réponse en s’appuyant sur des pages KV contenant des données d’autres requêtes, d’où la fuite observée pour les prompts > 681 280 tokens.

Mesures de remédiation et prévention

Cloudflare a d’abord élargi le pool KV à environ 2,04 millions de tokens, soit le double de la longueur de contexte, éliminant ainsi le chemin de rejet pour les requêtes valides. Ensuite, le moteur SGLang a été patché : les requêtes en cours de rejet sont retirées de la file d’admission avec l’erreur d’origine avant toute allocation ou transfert KV, et le nœud de décodage vérifie désormais que le nombre de tokens transférés correspond à celui réservé. Ces correctifs ont été proposés upstream (PR #38704) et intégrés dans les branches principales (#36988, #38935). Après validation, le modèle a été remis en production.

Cette incident montre que la concordance entre la taille du pool KV et la fenêtre de contexte, ainsi que la robustesse des chemins de rejet, sont essentielles pour éviter la contamination de mémoire dans les systèmes d’inférence à grande échelle.