Cloudflare a publié un rapport d'incident détaillé décrivant comment un bug de gestion du cache dans sa plate-forme d'IA sans serveur a amené au moins 155 utilisateurs d'un déploiement de modèle GLM-5.3 à recevoir des réponses contenant des fragments d'invites et de sorties d'autres clients. Le rapport, publié le 26 octobre en tant que divulgation coordonnée parallèlement au projet de moteur d'inférence open source SGLang, offre un rare aperçu public de la plomberie du service LLM multi-tenant – et un avertissement sur les hypothèses de sécurité de la mémoire GPU.
Comment la fuite a été trouvée Pour plus de contexte sur cette histoire, consultez notre plus d'articles sur l'IA.
Selon Cloudflare, le chercheur en sécurité Gadi Evron de Knostic a alerté l'entreprise le 8 septembre 2026, via son programme de bug bounty HackerOne. Evron a signalé que de très longues invites envoyées au modèle GLM-5.3 sur la plateforme Workers AI de Cloudflare renvoyaient parfois du texte appartenant aux sessions d'autres utilisateurs. Cloudflare a reproduit le problème le lendemain matin et désactivé le modèle le même jour, le restaurant le 9 septembre après avoir déployé des correctifs.
Le modèle concerné était @cf/zai-org/glm-5.3 — le modèle de codage agent de Z.ai que Cloudflare sert via Workers AI, la plateforme d'inférence sans serveur de l'entreprise. Cloudflare a confirmé qu'aucun autre modèle hébergé sur la plateforme n'était concerné.
Ce qui s'est réellement passé
L'incident remonte à deux problèmes qui se chevauchent, l'un opérationnel et l'autre lié au moteur lui-même.
Tout d’abord, la mauvaise configuration. Cloudflare a déployé GLM-5.3 avec une fenêtre contextuelle de 1 048 576 jetons, mais le pool de cache clé-valeur (KV) sur ses GPU de pré-remplissage n'avait de place que pour 681 280 jetons. La société a reconnu qu'elle était consciente de cette inadéquation avant le lancement et s'attendait à ce que le moteur d'inférence rejette les demandes trop longues en toute sécurité.
Deuxièmement, le bug du moteur. En mode pré-remplissage/décodage désagrégé – l'architecture utilisée par Workers AI, dans laquelle un pool de GPU traite l'invite et transmet le cache KV résultant à un pool distinct de GPU qui génèrent la réponse – SGLang a mal géré la demande de longueur excessive. Une invite qui ne correspondait pas au pool était marquée en interne comme rejetée et remplacée par un espace réservé à un jeton. Mais au lieu d'abandonner la requête et de renvoyer une erreur client, l'étape de pré-remplissage a généré un cache KV pour l'invite d'espace réservé et l'a transféré au nœud de décodage, qui a ensuite produit une réponse mêlant les données restantes des requêtes précédentes partageant les mêmes pages de mémoire.
Résultat : entre le 27 août et le 9 septembre, un petit nombre de clients utilisant le modèle ont reçu des réponses contenant des données provenant de demandes d'autres clients formulées peu avant la leur. Au total, 155 réponses ont été affectées – toutes, selon Cloudflare, concernaient des invites de plus de 681 280 jetons.
Aucune preuve d'exploitation délibérée
Cloudflare a déclaré qu'après avoir exclu ses propres tests et les demandes de validation du chercheur, les demandes concernées étaient cohérentes en termes de timing et de volume avec une utilisation ordinaire dans un contexte long, et la société n'a trouvé aucune preuve que quiconque ait délibérément exploité le bug. Étant donné que chaque demande concernée dépassait la capacité du pool sous-dimensionné, la fenêtre d'exposition était étroitement limitée – un côté positif qui découle de la mauvaise configuration à l'origine du problème.
La solution : des pools plus grands et un chemin de défaillance plus sûr
La remédiation a fonctionné sur les deux niveaux de la défaillance. Cloudflare a reconfiguré son déploiement GLM-5.3 pour correspondre à sa configuration GLM-5.2, libérant suffisamment de mémoire GPU pour que le pool KV de pré-remplissage contienne désormais environ 2,04 millions de jetons, soit environ le double de la longueur de contexte de 1 048 576 jetons du modèle. Une invite qui correspond à la fenêtre contextuelle correspond désormais toujours au pool.
Mais la société a également souligné que s'appuyer uniquement sur la taille du pool est fragile : les modifications apportées à la quantification, au parallélisme tensoriel, à la taille des graphiques CUDA ou à une future version du modèle peuvent modifier silencieusement la taille du pool. Ainsi, il a également corrigé le chemin de rejet de SGLang lui-même, garantissant qu'une requête rejetée s'interrompt proprement au lieu de générer et de transférer le cache pour un espace réservé. Les deux modifications ont été validées par rapport au script de reproduction du chercheur et aux propres tests de marqueurs Canary de Cloudflare avant la restauration du modèle, et les correctifs ont été apportés en amont aux responsables de SGLang.
Pourquoi la mémoire GPU partagée est une question de sécurité
Le rapport explique une pratique qui surprendra de nombreux développeurs d'applications : les moteurs d'inférence ne mettent généralement pas à zéro les pages de cache KV entre les requêtes, car la requête suivante les écrase simplement. Il s'agit d'un compromis délibéré en matière de performances, commun à tous les moteurs d'inférence, mais comme le montre cet incident, tout chemin permettant de générer une réponse avant que ces pages ne soient complètement écrasées transforme une optimisation des performances en un vecteur de fuite de données.
La divulgation a atterri dans la communauté des développeurs : l'histoire a atteint 123 points sur Hacker News en quelques heures, avec une discussion axée sur la façon dont le mode d'échec – une requête qui aurait dû échouer bruyamment au lieu de procéder silencieusement en cas de corruption – reflète les leçons classiques de l'ingénierie des systèmes distribués.
Une leçon plus large pour l'infrastructure d'IA
Cet incident rappelle que le périmètre de sécurité des applications d’IA s’étend désormais profondément dans l’infrastructure d’inférence. Le modèle de service multi-tenant concentre les données de nombreux clients via des accélérateurs partagés, des pools de cache partagés et des architectures de plus en plus exotiques telles que le pré-remplissage désagrégé et l'accès direct à la mémoire à distance. Une subtile inadéquation entre la fenêtre contextuelle annoncée d'un modèle et la capacité physique fournie pour la servir était suffisante pour rompre l'isolement des locataires.
Pour les entreprises qui s'appuient sur des plates-formes d'IA sans serveur, les conclusions du rapport de Cloudflare sont doubles : les bugs d'isolation des locataires dans le service LLM sont réels et se sont déjà produits en production, et le temps de réponse des fournisseurs - moins de 24 heures entre le signalement et la désactivation, un jour pour la correction et la restauration - est la norme de diligence à exiger de tout fournisseur traitant des invites sensibles.
---
Restez à la Pointe de l'IALes dernières actualités, analyses et percées en IA — au même endroit.
Lire plus d'actualités IA →
