Cloudflare Workers AI : GLM 5.3 a exposé des requêtes clients
Sur Workers AI, le modèle GLM 5.3 a exposé des fragments de requêtes d'autres clients pendant près de deux semaines.
Une faille peu banale a touché Workers AI, la plateforme d’IA de Cloudflare. Pendant près de deux semaines, le modèle GLM 5.3 a renvoyé des morceaux de requêtes à certains clients. Ces requêtes venaient d’autres utilisateurs. Le problème est désormais corrigé. Cependant, il illustre un risque encore mal maîtrisé dans l’hébergement des modèles de langage.
Workers AI : ce que l’on sait de l’incident
Tout commence le 8 septembre 2026. Un chercheur en sécurité externe signale à Cloudflare un comportement anormal de GLM 5.3. Ce modèle est développé par Z.ai. Par ailleurs, il est proposé aux développeurs sur Workers AI.
Le symptôme était clair. En effet, lorsqu’on lui soumettait une requête très longue, le modèle renvoyait parfois du texte issu des sessions d’autres personnes.
Cloudflare a publié son rapport le 26 octobre. Le modèle avait été mis en ligne le 27 août. Il a ensuite été corrigé le 9 septembre. Ainsi, entre ces deux dates, 155 réponses ont été concernées.
Toutes étaient liées à des requêtes dépassant 681 280 tokens. Il s’agit en effet de volumes considérables, comparables à de gros documents ou à des projets informatiques entiers.
Par ailleurs, l’entreprise affirme n’avoir trouvé aucune trace d’exploitation délibérée. Elle assure également qu’aucun autre de ses modèles n’a été touché.
Un cache partagé et un bug dans SGLang
L’origine de la fuite combine deux éléments. D’un côté, une erreur de dimensionnement. De l’autre, un bug dans SGLang, le logiciel open source qui fait tourner les modèles sur les serveurs.
Le rôle du cache KV
Pour répondre, un modèle lit d’abord la requête. Il en conserve ensuite une version intermédiaire dans la mémoire de ses processeurs graphiques. On parle de cache KV.
Cette mémoire est découpée en pages. Chaque requête en reçoit quelques-unes. Ensuite, ces pages sont réutilisées par la requête suivante, sans être effacées. Ainsi, le système gagne en rapidité.
En contrepartie, SGLang doit savoir précisément à qui appartient chaque page. Dans le cas contraire, les données d’un client peuvent se retrouver dans la réponse d’un autre.
Un écart entre promesse et capacité
Cloudflare annonçait que GLM 5.3 gérait des requêtes d’un peu plus d’un million de tokens. Pourtant, la mémoire des machines chargées de lire ces requêtes n’en acceptait que 681 280.
Les équipes connaissaient cet écart. Elles pensaient toutefois que SGLang rejetterait simplement les requêtes trop longues.
Ce n’était pas le cas. En effet, chez Cloudflare, le traitement est réparti entre deux groupes de machines. Les unes lisent la requête. Les autres rédigent la réponse.
Face à une requête trop longue, les premières la remplaçaient par un contenu factice très court. Elles ne prévenaient pas les secondes.
Or ces dernières attendaient la requête complète. Elles allaient donc chercher la suite dans des pages de mémoire jamais réécrites. Ces pages contenaient encore les requêtes d’autres utilisateurs.
Le client recevait alors une réponse cohérente, sans message d’erreur. Elle pouvait pourtant contenir des fragments de conversations qui ne le concernaient pas.
Pourquoi Workers AI n’a rien détecté plus tôt
Les tests de Cloudflare avaient une limite importante. D’abord, ils vérifiaient que le service répondait sans erreur. En revanche, ils ne contrôlaient pas le contenu des réponses.
Dans ces conditions, une réponse fluide mais erronée passait inaperçue. Autrement dit, l’absence d’erreur technique masquait la fuite.
Le bug avait d’ailleurs été signalé aux développeurs de SGLang dès juillet. Il n’était donc pas totalement inconnu.
Une fois l’incident déclaré, la réaction a été rapide. Cloudflare a coupé l’accès public à GLM 5.3 en moins de 40 minutes. Le modèle est ensuite revenu en ligne le soir même. Entre-temps, l’entreprise avait agrandi la mémoire disponible et corrigé le logiciel.
Le problème dépasse toutefois le seul cas de Cloudflare. En effet, SGLang est utilisé par d’autres entreprises. C’est pourquoi Cloudflare demande à tous les opérateurs concernés de passer à la version 0.5.22, publiée le 19 octobre.
L’entreprise reste lucide sur la portée de ces correctifs. Ils réduisent le risque, mais ne l’éliminent pas. Par ailleurs, elle prévient que la prochaine faille aura une forme inédite.
Elle travaille donc avec les développeurs de SGLang sur un mécanisme plus robuste. Son objectif : empêcher une requête de lire une page de mémoire qui ne lui appartient pas.
Ce qu’il faut retenir
- Période concernée : du 27 août au 9 septembre 2026, avec une alerte le 8 septembre.
- Ampleur : 155 réponses, toutes liées à des requêtes de plus de 681 280 tokens.
- Cause : un cache KV trop petit par rapport à la fenêtre de contexte annoncée, associé à un bug de SGLang.
- Correction : mémoire agrandie, logiciel corrigé et accès rétabli le soir du 9 septembre.
- Action recommandée : mettre à jour SGLang vers la version 0.5.22 si vous l’exploitez dans une configuration similaire.
Par ailleurs, les équipes qui déploient des modèles d’IA devraient tester le contenu des réponses, et pas seulement leur disponibilité. De plus, il vaut mieux vérifier que les limites annoncées correspondent aux capacités réelles de l’infrastructure. Enfin, isoler strictement la mémoire de chaque requête reste la meilleure protection.