Cloudflare révèle une fuite entre requêtes dans un modèle GLM-5.3 hébergé

Cloudflare révèle une fuite entre requêtes dans un modèle GLM-5.3 hébergé

Le 26 octobre, Cloudflare a publié un rapport post-incident sur un défaut d'isolation entre locataires dans son service Workers AI. Un chercheur en sécurité, Gadi Evron de Knostic, avait signalé le 8 septembre que des invites très longues envoyées au modèle GLM-5.3 (`@cf/zai-org/glm-5.3`) renvoyaient parfois du texte provenant des sessions d'autres clients. Selon Cloudflare, l'exposition a commencé au lancement du modèle, le 27 août ; l'entreprise l'a mis hors ligne le 9 septembre et l'a rétabli le jour même, et aucun autre modèle de Workers AI n'a été touché. Le rapport est daté du 26 octobre parce qu'il a été coordonné avec un article de SGLang, le moteur d'inférence open source concerné. L'incident lui-même date d'environ sept semaines plus tôt. Ce numéro du 27 octobre rend compte de la divulgation, pas d'une nouvelle attaque.

Cloudflare donne un chiffre : 155 réponses ont été touchées, toutes pour des invites de plus de 681 280 jetons. Ici, un jeton est une unité de texte lue par le modèle, et non une cryptomonnaie. Après avoir écarté ses propres tests et ceux du chercheur, Cloudflare affirme que les requêtes restantes correspondent, par leur calendrier et leur volume, à un usage ordinaire du contexte long, et qu'il n'a trouvé aucune preuve d'exploitation délibérée. C'est la conclusion de l'entreprise elle-même. L'article ne précise ni le nombre de clients concernés ni le contenu du texte qui a fuité.

Deux défauts qui se sont additionnés

Le premier défaut était une incohérence de configuration. Cloudflare a déployé le modèle avec une fenêtre de contexte de 1 048 576 jetons, alors que le pool de mémoire GPU qui contient le cache d'attention (le cache KV) sur ses GPU de préremplissage ne pouvait en accueillir que 681 280. L'entreprise dit qu'elle connaissait cet écart avant le lancement et qu'elle s'attendait à ce que le moteur renvoie une erreur pour toute invite qui ne tiendrait pas. Ses tests en contexte long renvoyaient des réponses réussies, et l'équipe n'a donc pas vu de problème. Elle reconnaît aujourd'hui que ces tests vérifiaient les codes HTTP et la vitesse, mais pas la cohérence de la sortie.

Le second défaut était un bogue de SGLang lorsque le préremplissage et le décodage tournent sur des pools de GPU séparés. Une invite trop longue pour le pool était marquée comme rejetée et remplacée par une invite de substitution d'un seul jeton, mais la requête n'était pas arrêtée. Le préremplissage écrivait une seule page de cache et indiquait au nœud de décodage que le transfert était terminé. Dans l’exemple du schéma de Cloudflare, ce dernier réserve huit pages pour la vraie invite et suppose que les huit sont neuves. Sept contiennent encore des données de requêtes précédentes, et le modèle répondait donc en lisant les restes d'autres utilisateurs. Le client recevait une réponse de succès normale, pas une erreur. Cloudflare note que les pages de cache ne sont pas remises à zéro entre deux requêtes. Les moteurs acceptent couramment ce choix pour la vitesse, ce qui oblige le moteur à suivre lui-même à qui appartient chaque page.

Ce que Cloudflare a changé

La chronologie du rapport est la suivante. L'incident a été déclaré le 9 septembre à 13 h 22 UTC. Le modèle a été passé en privé à 14 h 00, la cause racine a été trouvée à 14 h 35, et le modèle est revenu en accès public à 19 h 40 avec une configuration corrigée et un moteur corrigé. Le pool de préremplissage contient désormais environ 2,04 millions de jetons, soit à peu près le double de la fenêtre de contexte, de sorte qu'une invite valide tient toujours. Cloudflare a aussi corrigé le moteur pour qu'une requête rejetée soit retirée avant le début de tout transfert de cache. SGLang a publié des correctifs liés dans les versions v0.5.20 à v0.5.22, et Cloudflare demande à tous ceux qui exploitent SGLang en mode désagrégé de passer à la v0.5.22 ou à une version ultérieure. Le rapport cite aussi un durcissement plus large : libération différée des pages de cache, lots de transfert bornés, et contrôle avant déploiement comparant la taille du pool à la longueur du contexte.

Ce que les lecteurs peuvent en retenir

Pour ceux qui achètent de l'inférence hébergée, la leçon est étroite mais concrète. D'après le rapport, les requêtes qui ont reçu du texte divulgué avaient des invites de plus de 681 280 jetons. La longueur des requêtes des autres clients dont les données ont été exposées n'est pas indiquée. Reste qu'un défaut d'isolation peut rester silencieux pendant 13 jours sans aucune erreur, comme ici. Les équipes qui exploitent leur propre moteur devraient comparer la capacité du cache à la longueur de contexte annoncée, tester le contenu des sorties et pas seulement les codes d'état, et garder un canal clair pour que des chercheurs externes signalent les défauts. Le récit de Cloudflare est un compte rendu du fournisseur lui-même. L'article ne contient aucune vérification indépendante de ses chiffres et ne quantifie pas l'impact sur les clients.