Cloudflare explique la fuite de GLM 5.3 sur 155 réponses

Cloudflare a détaillé le 26 octobre l’origine d’une fuite liée à GLM 5.3, son modèle développé par Z.ai et proposé sur Workers AI. Entre le 27 août et le 9 septembre 2026, certaines réponses ont intégré des fragments de requêtes envoyées par d’autres utilisateurs. Cloudflare a recensé 155 réponses concernées. Toutes étaient associées à des requêtes dépassant 681 280 tokens, soit des documents ou projets informatiques volumineux. L’alerte est venue d’un chercheur en sécurité externe le 8 septembre. Il avait signalé un comportement anormal du modèle. L’entreprise a ensuite enquêté sur l’incident et publié son rapport le 26 octobre. Lire le rapport de Cloudflare.

Le défaut combinait une mémoire insuffisante et un problème dans SGLang, le logiciel chargé de faire fonctionner les modèles sur les serveurs. Cloudflare annonçait une capacité légèrement supérieure à un million de tokens pour GLM 5.3. Pourtant, la mémoire disponible sur les machines ne pouvait en accueillir que 681 280. Les équipes connaissaient cet écart. Elles pensaient que SGLang refuserait les requêtes trop longues. Leurs tests vérifiaient seulement que le service répondait sans erreur. Ils ne contrôlaient pas le contenu produit. Cette hypothèse a laissé passer les requêtes trop longues dans le système. L’article original de Numerama décrit ce mécanisme.

681 280 tokens dépassaient la mémoire

Le cache KV conservait une version intermédiaire de chaque requête dans la mémoire des processeurs graphiques. Cette mémoire était découpée en pages attribuées aux requêtes, puis réutilisées. Les pages devaient donc rester rattachées au bon client. Face à une requête trop longue, les machines chargées de la lire la remplaçaient par un contenu factice très court. Elles ne prévenaient pas les machines chargées de rédiger la réponse. Ces dernières attendaient la requête complète. Elles cherchaient alors la suite dans des pages qui n’avaient pas été réécrites. Ces pages contenaient encore des fragments d’autres requêtes. La réponse pouvait rester cohérente et ne produire aucun message d’erreur.

Cloudflare a coupé l’accès public à GLM 5.3 moins de 40 minutes après la déclaration de l’incident. L’entreprise l’a rétabli le soir même, après avoir augmenté la mémoire disponible et corrigé le logiciel. Elle affirme n’avoir trouvé aucune preuve d’exploitation délibérée. Elle indique également qu’aucun autre modèle n’a été touché. Le bug de SGLang avait été signalé à ses développeurs dès juillet. Le logiciel étant utilisé par d’autres entreprises, Cloudflare recommande aux opérateurs concernés d’installer la version 0.5.22. Cette version a été publiée le 19 octobre. La recommandation vise les configurations similaires à celle qui a provoqué l’exposition chez Cloudflare.

Cloudflare recommande SGLang 0.5.22

Le correctif réduit les risques sans les éliminer complètement, selon Cloudflare. L’entreprise prévient que « le prochain bug aura une forme inédite ». Elle travaille donc avec les développeurs de SGLang sur un mécanisme destiné à empêcher une requête de lire une page mémoire appartenant à une autre. L’incident associe ainsi une capacité annoncée supérieure à la mémoire réellement disponible, un refus défaillant des requêtes trop longues et une réutilisation de pages non effacées. Les 155 réponses concernées correspondent toutes au seuil de 681 280 tokens. Cloudflare demande désormais aux opérateurs de SGLang de passer à la version 0.5.22 dans les configurations comparables.