Cloudflare affirme qu’un bogue de GLM-5.3 a divulgué 155 réponses entre les sessions de différents clients

Le 26 octobre 2026, Cloudflare a publié un rapport d’incident révélant une exposition du cache KV entre différentes requêtes dans le modèle GLM-5.3 de sa plateforme Workers AI. Ainsi, 155 réponses à des requêtes très longues contenaient des données provenant des sessions d’autres clients.

Le chercheur en sécurité Gadi Evron, de Knostic, a signalé à Cloudflare le problème d’isolation entre clients le 8 septembre 2026, par l’intermédiaire du programme HackerOne de l’entreprise. L’exposition concernait le modèle proposé sous le nom @cf/zai-org/glm-5.3 depuis le 27 août 2026, jour de son lancement sur Workers AI. Cloudflare a corrigé le problème et rétabli le modèle le 9 septembre 2026, et a indiqué avoir confirmé qu’aucun autre modèle hébergé sur Workers AI n’avait été touché.

Les 155 réponses touchées concernaient des requêtes de plus de 681 280 jetons. Cloudflare a indiqué qu’après exclusion de ses propres tests et des requêtes du chercheur, les requêtes recensées correspondaient, par leur fréquence et leur volume, à un usage ordinaire du contexte long plutôt qu’à une exploitation répétée du bogue, et qu’elle n’avait trouvé aucun signe d’exploitation délibérée.

Les deux problèmes à l’origine de l’exposition

GLM est un modèle de génération de texte de Z.ai conçu pour les flux de travail de programmation agentique. Il fait partie des nombreux modèles accessibles par l’intermédiaire de Workers AI. Cloudflare exécute GLM 5.3 avec SGLang, un moteur d’inférence open source, dans une configuration désagrégée : les processeurs graphiques de préremplissage traitent la requête et produisent son cache KV, puis transfèrent ce cache, au moyen de l’accès direct à la mémoire à distance (RDMA) et de Mooncake, aux processeurs graphiques de décodage qui génèrent la réponse. Le cache KV est un pool partagé de pages de taille fixe. Ces pages ne sont pas remises à zéro entre les requêtes : le moteur doit donc suivre à qui appartient chacune d’elles.

Le rapport attribue l’exposition à deux problèmes. Le premier était une erreur de configuration : Cloudflare avait déployé GLM 5.3 avec une fenêtre de contexte de 1 048 576 jetons, alors que le pool de cache KV de ses processeurs graphiques de préremplissage ne pouvait en contenir que 681 280. Cloudflare a indiqué qu’elle connaissait cet écart avant le lancement, mais s’attendait à ce que le moteur renvoie une erreur pour toute requête qu’il ne pouvait pas traiter. Comme ses tests en contexte long avaient renvoyé des réponses réussies, elle ne pensait pas que cet écart posait problème. L’entreprise a précisé que ses tests vérifiaient les codes de réponse HTTP et les performances du moteur en contexte long, mais pas les résultats du modèle ni leur cohérence. Elle vérifie désormais directement la taille du pool KV par rapport à la longueur du contexte avant de déployer toute modification d’une configuration désagrégée.

Le second problème était un bogue de SGLang dans la gestion des requêtes dépassant la capacité disponible en mode désagrégé de préremplissage et de décodage. Une requête qui ne tenait pas dans le pool était marquée en interne comme rejetée, puis remplacée par un espace réservé d’un jeton. Cependant, le préremplissage produisait quand même un cache KV pour cet espace réservé et signalait que le transfert était terminé. Le nœud de décodage générait alors une réponse en s’appuyant sur des pages de cache obsolètes qui contenaient encore des données de requêtes précédentes, et le client recevait une réponse HTTP 200 au lieu d’une réponse HTTP 400.

L’équipe SGLang indique dans sa propre publication coordonnée que le chemin de rejet sur un seul nœud renvoyait une erreur à la place. Le problème ne survenait donc que dans le service désagrégé. Un autre utilisateur avait signalé le bogue à SGLang sous le numéro de problème #30233 le 6 juillet 2026. Cloudflare a indiqué l’avoir repéré au cours de son enquête.

Gestion de l’incident et mesures correctives

Cloudflare a commencé à vérifier le signalement à 08:00 UTC le 9 septembre 2026 et a déclaré un incident de sécurité à 13:22, après que son équipe de sécurité des produits a reproduit la fuite à l’aide de deux comptes indépendants en moins de 25 minutes. À 14:00, elle a rendu GLM 5.3 privé ; à 14:35, elle avait identifié la cause fondamentale ; à 14:52, elle avait déployé la configuration corrigée sur tous les nœuds de préremplissage ; à 19:04, elle avait reconstruit l’ensemble du déploiement avec un correctif du moteur développé par Cloudflare ; et à 19:40, elle avait rétabli l’accès public au modèle. La page d’état de Cloudflare indique que l’incident de Workers AI a commencé à 10 h 25 EDT le 9 septembre 2026, qu’il a été identifié à 11 h 02 EDT et qu’il a été résolu à 16 h 09 EDT.

La correction de configuration reprenait celle utilisée pour GLM 5.2 et libérait suffisamment de mémoire GPU pour que le pool KV de préremplissage puisse désormais contenir environ 2,04 millions de jetons, soit environ deux fois la longueur de contexte de 1 048 576 jetons. Ainsi, toute requête qui tient dans la fenêtre de contexte tient toujours dans le pool. Le correctif du moteur retire, dès la file d’admission de la désagrégation, toute requête faisant l’objet d’un rejet en attente, en conservant son erreur d’origine et avant toute initialisation, allocation ou tout transfert KV. Avant de rétablir le modèle, Cloudflare a validé les deux modifications à l’aide du script de reproduction du chercheur et de ses propres tests avec marqueurs canaris.

Correctifs intégrés au projet et travaux en cours

Cloudflare a proposé son correctif au projet SGLang sous la forme de la demande de fusion #38704. Les responsables du projet ont fusionné la #38935, qui rejette les requêtes concernées dès leur admission selon l’approche de Cloudflare. Un correctif connexe, la #36988, avait été fusionné le 6 septembre 2026 pour un autre chemin de défaillance lié. Le correctif a été intégré à SGLang v0.5.20, puis complété dans les versions v0.5.21, publiée le 2 octobre 2026, et v0.5.22, publiée le 19 octobre 2026. Cloudflare recommande à tous les opérateurs de SGLang de passer à la version v0.5.22 ou ultérieure. L’équipe SGLang indique que la v0.5.21 protège par défaut les déploiements Mooncake et NIXL contre tous les types de défaillance, que les déploiements MORI nécessitent une compilation de la v0.5.22 et que le correctif n’a pas été rétroporté vers les branches de versions antérieures.

L’équipe SGLang a indiqué que, sur 21 essais effectués avec deux GPU H100, les variations de débit avec les protections restaient dans une fourchette de ±2 %, et que chaque intervalle de confiance à 95 % incluait zéro. Elle a également précisé qu’une série distincte de 16 essais sur deux GPU H200 avait mesuré à −0,38 % le coût de l’activation par défaut de la libération différée du KV, avec un intervalle de confiance allant de −2,12 % à +1,36 %, résultat qu’elle a qualifié de non significatif. Cloudflare a rencontré les responsables de la maintenance de SGLang chez RadixArk le 10 septembre 2026, a déployé des mesures de renforcement supplémentaires sur l’ensemble de ses déploiements SGLang en production entre le 11 et le 19 septembre 2026, et les fusions en amont couvrant le correctif à l’admission, les sommes de contrôle pour chaque transfert, la préservation des accusés de réception d’interruption et l’activation par défaut de la libération différée du KV se sont échelonnées du 16 septembre au 12 octobre 2026.

Pour les autres opérateurs qui exécutent SGLang en mode désagrégé, le rapport de Cloudflare recommande de mesurer la taille du pool KV en fonction de la longueur du contexte sur chaque nœud de préremplissage et de décodage après toute modification des poids, de la quantification, du parallélisme ou de la fraction de mémoire ; de passer à une version qui inclut les deux correctifs à l’admission ; d’activer la libération différée du KV pour les deux rôles ; d’activer la détection de corruption lorsque le modèle la prend en charge ; et de configurer les équilibreurs de charge de façon à ce que la déconnexion d’un client n’interrompe pas une requête au milieu d’un transfert.

Cloudflare a indiqué avoir précédemment conçu un prototype qui étiquette chaque page KV physique et vérifie la correspondance avant que le décodage ne lise le cache, et dont le coût, lors des tests, était inférieur à 1 % en débit et en latence de queue ; l’entreprise a testé ce prototype avec GLM 5.2 à la mi-août 2026, mais l’a désactivé peu après en raison de problèmes de fiabilité. Cloudflare travaille avec l’équipe SGLang à une version de production intégrée au moteur, la somme de contrôle par transfert de la demande de fusion n° 39500 constituant une première étape. L’entreprise a également déclaré mettre son expérience des méthodes formelles à profit pour modéliser et prouver la sûreté d’un protocole de transfert de cache KV fondé sur RDMA et utilisant Mooncake dans son déploiement SGLang en production.

Dans son billet, l’équipe SGLang remercie les ingénieurs de Cloudflare Kevin Flansburg et Kastan Day pour leur travail sur les correctifs et indique que la divulgation coordonnée par SGLang et Cloudflare, le 26 octobre 2026, constitue la dernière entrée de sa chronologie de divulgation. Le rapport du chercheur lui-même, qui décrira la découverte et sa validation externe, est à paraître.