Cloudflare a révélé le 26 octobre 2026 une défaillance d'isolation entre clients dans le modèle GLM-5.3 hébergé sur Workers AI. Selon le rapport officiel de l'entreprise, 155 réponses contenaient des données issues de requêtes d'autres clients, entre le 27 août et le 9 septembre 2026. Toutes les réponses concernées correspondaient à des prompts de plus de 681 280 tokens.
Ce sujet est classé ici comme CONFIRMÉ, car il repose sur une divulgation officielle. Il n'a pas touché les prompts ordinaires. Cloudflare affirme qu'aucun autre modèle de Workers AI n'a été affecté et qu'elle n'a trouvé aucune preuve d'exploitation délibérée. L'entreprise évoque seulement un « petit nombre de clients » concernés, sans préciser combien.
Comment deux défaillances se sont combinées
La première cause était une configuration incompatible : GLM-5.3 a été lancé avec une fenêtre de contexte de 1 048 576 tokens, alors que le pool de cache KV des GPU de prefill ne contenait que 681 280 tokens. Cloudflare indique qu'elle connaissait déjà cet écart et s'attendait à ce que le moteur renvoie une erreur pour les prompts ne tenant pas dans le pool.
La seconde cause était un bogue dans SGLang, le moteur d'inférence open source utilisé par la plateforme, en mode désagrégé prefill/decode. Un prompt trop long était marqué en interne comme rejeté et remplacé par un espace réservé d'un seul token, mais au lieu d'interrompre la requête avec une erreur, le système a continué. Le nœud de decode a reçu le signal de transfert terminé et a généré sa réponse en lisant des pages de cache qui contenaient encore des données de requêtes antérieures. Le client recevait HTTP 200, et non HTTP 400, avec une réponse d'apparence cohérente.
Chronologie et correctif
Le chercheur Gadi Evron, de Knostic, a signalé le problème le 8 septembre 2026 via le programme HackerOne de Cloudflare. Le 9 septembre, l'entreprise a déclaré l'incident, retiré le modèle dans les 40 minutes suivant la déclaration et l'a restauré le même jour, avec la configuration corrigée et un moteur corrigé.
Dans le correctif, le pool de prefill a été porté à environ 2,04 millions de tokens, soit à peu près le double de la fenêtre de contexte. Cloudflare a également corrigé le chemin de rejet dans le moteur et recommande à tous les opérateurs de mettre à jour SGLang vers la version 0.5.22 ou ultérieure. Le correctif principal est arrivé dans SGLang 0.5.20, avec des suites dans les versions 0.5.21 et 0.5.22.
Pourquoi cela compte
Ce cas illustre un risque concret de l'inférence partagée à grande échelle : le cache KV est une frontière d'isolation entre clients, et pas seulement un détail de performance. Quand la taille du pool et celle de la fenêtre de contexte ne sont pas vérifiées ensemble, et que le chemin d'erreur n'est pas testé avec la sortie réelle du modèle, un échec peut ressembler à un succès, avec un code 200 et un nombre de tokens plausible.
Pour les équipes qui exploitent SGLang elles-mêmes, la leçon directe est de vérifier la taille du pool KV par rapport à la fenêtre de contexte à chaque changement de déploiement et de maintenir le moteur à jour. Pour les utilisateurs d'API hébergées, l'épisode rappelle la prudence avec les données sensibles dans des prompts très longs, même lorsque la réponse semble normale.
Crédit image : diagramme publié par Cloudflare dans son rapport officiel sur l'exposition du cache KV de GLM-5.3.
Sources
- Cloudflare — Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang
- Unite.AI — Cloudflare Says GLM-5.3 Bug Leaked 155 Responses Across Tenant Sessions
- AICoder — Cloudflare discloses a cross-request KV cache leak in GLM-5.3 on Workers AI
Transparence : cet article a été produit avec l'aide de l'intelligence artificielle, à partir de recherches dans des sources publiques sur internet, y compris le rapport officiel de Cloudflare. Consultez les sources originales listées ci-dessus avant de prendre des décisions techniques.
Muse
