Cloudflare et la perte d'isolation dans le cache KV : le cas du modèle GLM-5.3

Le 26 octobre 2026, Cloudflare a publié les détails d'un incident de sécurité. Entre le 27 août et le 9 septembre 2026, le modèle GLM-5.3 de Workers AI a renvoyé à certains clients des réponses contenant des données issues des requêtes d'autres utilisateurs. L'incident a touché 155 réponses, toutes générées à partir de prompts de plus de 681 280 tokens. Selon Cloudflare, aucun autre modèle de Workers AI n'a été touché. La fuite avait deux causes. La première était un écart de configuration entre la fenêtre de contexte du modèle (1 048 576 tokens) et la capacité du pool de cache KV sur les GPU de prefill (681 280 tokens). Cloudflare le connaissait avant le lancement, mais ne pensait pas qu'il poserait problème. La seconde était un bug du moteur d'inférence open source SGLang.

D'après la reconstitution de l'entreprise, lorsqu'un prompt dépassait la limite du cache KV, SGLang en mode désagrégé marquait la requête comme rejetée et la remplaçait par un espace réservé, sans arrêter le flux. Les files d'admission vérifiaient seulement si l'exécution était terminée, pas si la requête avait été rejetée. Le nœud de decode pouvait donc lire des pages mémoire qui contenaient encore les données de prompts précédents, puis renvoyer au client un code HTTP 200 au lieu d'une erreur. Un problème similaire avait déjà été signalé sur le dépôt de SGLang le 6 juillet 2026, dans l'issue #30233. Selon Unite.AI, qui s'appuie sur le rapport officiel, les vérifications de Cloudflare avant le lancement portaient sur les codes de réponse HTTP et les performances en contexte long, mais pas sur l'exactitude de la sortie finale du modèle.

Le chercheur en sécurité Gadi Evron, de Knostic, a signalé l'incident le 8 septembre 2026 via HackerOne. Le 9 septembre (UTC), Cloudflare a déclaré l'incident à 13 h 22, après l'avoir reproduit depuis deux comptes distincts. Le modèle a été rendu privé à 14 h 00 et la cause identifiée à 14 h 35. Il est redevenu public à 19 h 40, une fois le pool de cache KV de prefill porté à environ 2,04 millions de tokens. C'est à peu près le double de la fenêtre de contexte, comme dans la configuration de GLM 5.2. Le correctif de SGLang, qui écarte désormais les requêtes rejetées avec leur erreur d'origine avant tout transfert KV, a été proposé en amont (#38704) et figure dans SGLang depuis la v0.5.20. La publication du rapport a été coordonnée avec les mainteneurs de SGLang (RadixArk). Cloudflare recommande aux utilisateurs de SGLang de passer à la v0.5.22 ou ultérieure et de comparer, sur chaque nœud, la taille du pool KV à la longueur de contexte. Plusieurs questions restent toutefois ouvertes. Dans son rapport, Cloudflare affirme n'avoir trouvé aucune preuve d'exploitation délibérée (« We found no evidence of deliberate exploitation »), mais il s'agit d'une évaluation interne qu'aucun tiers n'a vérifiée. Cloudflare ne dit pas combien de clients ont été concernés et parle seulement d'un petit nombre. L'entreprise ne précise pas non plus la nature exacte des données exposées dans les 155 réponses, ni si et comment les clients concernés ont été prévenus. Le rapport de recherche d'Evron n'a pas encore été publié.

Séparer prefill et decode sur des infrastructures distinctes rend les longs contextes abordables, mais déplace la frontière de sécurité vers l'intégrité de la mémoire GPU partagée. Quand l'optimisation des ressources et les tests de performance passent avant le contrôle de la sortie, un seul état d'erreur non intercepté suffit à transformer l'efficacité en perte accidentelle d'isolation. — Olya