Cloudflare a révélé le 26 octobre que 155 réponses de son service Workers AI ont contenu des fragments de requêtes d’autres clients, entre le 27 août et le 9 septembre 2026. En cause : le modèle GLM-5.3, une erreur de dimensionnement de sa mémoire de calcul et un bogue du moteur d’inférence libre SGLang. L’incident illustre un risque propre à l’IA mutualisée, que toute entreprise cliente d’un fournisseur d’inférence a intérêt à comprendre.
Ce qui s’est passé
D’après le rapport d’incident de Cloudflare, publié le même jour qu’une note de l’équipe SGLang, un seul modèle était concerné : GLM-5.3, conçu par la société Z.ai et proposé sur Workers AI depuis le 27 août. Le défaut existait dès cette mise en ligne. Le chercheur Gadi Evron, de l’entreprise Knostic, l’a signalé le 8 septembre par le programme de chasse aux bogues de Cloudflare sur HackerOne. Le 9 septembre, l’équipe de sécurité a reproduit la fuite en moins de 25 minutes à l’aide de deux comptes distincts, rapporte Unite.AI. Le modèle a été retiré de l’accès public à 14 h (heure UTC), corrigé dans la journée, puis rouvert à 19 h 40.
Toutes les réponses touchées faisaient suite à des requêtes très longues, au-delà de 681 280 jetons, l’unité de texte que manipulent les modèles. Cloudflare évoque « un petit nombre de clients » sans les chiffrer, affirme n’avoir relevé aucun signe d’exploitation délibérée et assure qu’aucun autre modèle de sa plateforme n’a été atteint. Son rapport ne dit pas si les clients concernés ont été prévenus un par un.
Une réserve trop petite et un bogue qui se sont additionnés
Pour servir GLM-5.3, Cloudflare répartit le travail entre deux groupes de processeurs graphiques. Le premier lit la requête et construit une mémoire de travail, appelée cache KV ; le second s’en sert pour rédiger la réponse, après un transfert par le réseau. Cette mémoire est découpée en pages qui passent d’une requête à l’autre sans être effacées : le moteur doit donc suivre avec rigueur à qui appartient chaque page.
Premier défaut : le modèle était proposé avec une fenêtre de contexte de 1 048 576 jetons, alors que la réserve de cache n’en contenait que 681 280. Cloudflare connaissait cet écart avant le lancement et comptait sur le moteur pour refuser proprement les requêtes trop longues. Or ses essais sur de longs contextes contrôlaient les codes de réponse et la vitesse, jamais la cohérence du texte produit. Second défaut, dans SGLang : en mode réparti, une requête trop longue était bien marquée comme refusée, mais un leurre d’un seul jeton prenait sa place et poursuivait le circuit. L’étage de rédaction lisait alors des pages périmées, garnies de prompts et de débuts de réponses d’autres utilisateurs, et renvoyait un code de succès au lieu d’une erreur. Ce bogue avait déjà été signalé aux développeurs du moteur le 6 juillet.
Les correctifs, et la leçon pour les tests
Cloudflare a porté sa réserve de cache à environ 2,04 millions de jetons, près du double du contexte annoncé, et modifié le moteur pour que toute requête refusée s’arrête avant le moindre transfert. Les corrections ont été intégrées au projet SGLang. Selon son équipe, les configurations réparties étaient exposées par défaut depuis la branche 0.4, apparue début 2025. La version 0.5.21, publiée le 2 octobre, protège les déploiements fondés sur Mooncake et NIXL ; ceux qui utilisent MORI doivent passer à la 0.5.22. Cloudflare recommande cette dernière ou une plus récente, et contrôle désormais la taille du cache face à la longueur de contexte avant chaque changement de déploiement. Les correctifs n’ont pas été reportés sur les anciennes branches du moteur.
La leçon dépasse ce cas précis. Pendant près de deux semaines, la plateforme a répondu « succès » tout en servant des données qui n’appartenaient pas au demandeur : un contrôle qui vérifie seulement que le service répond ne dit rien de ce qu’il répond.
Les questions à poser à son fournisseur d’IA
Une PME qui confie des contrats, des fiches clients ou du code source à une interface d’IA partagée n’a pas la main sur ces réglages. Elle peut en revanche interroger son prestataire sur quelques points précis :
- comment la mémoire de calcul est-elle isolée entre clients, et les pages réutilisées sont-elles effacées ou vérifiées ?
- quel moteur d’inférence, dans quelle version, et sous quel délai les correctifs de sécurité sont-ils appliqués ?
- les tests de mise en production examinent-ils le contenu des réponses, ou seulement leur disponibilité ?
- quelle procédure d’information est prévue si des données d’un client apparaissent chez un autre ?
Côté usages, il est prudent de ne pas envoyer des dossiers entiers dans des requêtes géantes lorsque quelques extraits suffisent, et de réserver les informations les plus sensibles à des offres dédiées ou à des modèles exécutés sur ses propres machines. Le cas Cloudflare montre aussi l’intérêt d’un signalement public détaillé : sans la vigilance d’un chercheur extérieur, la fuite aurait pu durer bien plus longtemps.
Questions fréquentes
Quelles données ont pu fuiter via Workers AI ?
Des morceaux de prompts et de réponses partielles d’autres utilisateurs du modèle GLM-5.3, glissés dans 155 réponses à des requêtes de plus de 681 280 jetons, entre le 27 août et le 9 septembre 2026, selon Cloudflare.
Les autres modèles de Cloudflare sont-ils concernés ?
Non, d’après Cloudflare, qui dit avoir vérifié qu’aucun autre modèle hébergé sur Workers AI n’était touché. L’entreprise a toutefois appliqué les correctifs et les protections supplémentaires à tous les modèles qu’elle sert avec SGLang.
Que doivent faire les entreprises qui hébergent elles-mêmes SGLang ?
Passer à la version 0.5.22 ou à une plus récente, recommande Cloudflare ; l’équipe SGLang conseille aussi un routeur qui annule les deux moitiés d’une requête interrompue. Cloudflare compare désormais la taille de sa réserve de cache à la longueur de contexte avant chaque déploiement, et SGLang propose une vérification d’intégrité facultative, désactivée par défaut. Sur une installation à un seul serveur, sans séparation des deux étages, le refus fonctionnait normalement et renvoyait bien une erreur, selon les deux rapports.
Sources
- Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang — Cloudflare (blog), 2026-10-26
- SGLang security update: improving request isolation — LMSYS / équipe SGLang, 2026-10-26
- Cloudflare Says GLM-5.3 Bug Leaked 155 Responses Across Tenant Sessions — Unite.AI, 2026-10-26