Des clients du service d'IA de Cloudflare ont reçu par erreur des données d'autres clients

Le 8 septembre à 23 h 11 (heure UTC), un signalement arrive sur le programme de chasse aux bugs de Cloudflare. Gadi Evron, de l'entreprise de sécurité Knostic, y décrit un comportement anormal : GLM-5.3, un modèle de langage proposé par Cloudflare sur son service Workers AI, renvoie parfois des réponses qui contiennent des données issues des requêtes d'autres clients. Le lendemain, les équipes de sécurité de Cloudflare reproduisent la fuite avec deux comptes distincts.

Le 26 octobre, l'entreprise a publié le récit complet de l'incident. Entre le lancement du modèle, le 27 août, et sa correction, le 9 septembre, 155 réponses ont contenu des données tirées de requêtes envoyées peu avant au même modèle par d'autres clients. Un « petit nombre » de clients sont concernés, selon Cloudflare, qui ne les nomme pas et ne précise pas s'ils ont été prévenus. Aucun autre modèle de Workers AI n'a été touché.

Une mémoire trop petite, et une erreur qui n'en renvoyait pas

Pour rédiger sa réponse, un modèle d'IA garde en mémoire une représentation du texte qu'il vient de lire, le « cache KV ». Chez Cloudflare, la lecture de la requête et la rédaction de la réponse se font sur des machines différentes. Or la réserve de mémoire prévue pour la lecture ne pouvait contenir que 681 280 tokens (des fragments de mots), alors que le modèle acceptait des textes de 1 048 576 tokens. Cloudflare reconnaît qu'il connaissait cet écart avant le lancement. Il ne l'a pas jugé gênant, car ses tests sur de longs textes renvoyaient des codes de succès. Le contenu des réponses, lui, n'était pas vérifié.

Le second ingrédient venait de SGLang, le logiciel libre qui fait tourner le modèle. Face à une requête trop longue, il ne renvoyait pas d'erreur : il la remplaçait par un texte d'un seul token. La machine chargée de rédiger travaillait alors avec des restes de mémoire laissés par des requêtes précédentes. Les 155 réponses fautives répondaient toutes à des requêtes de plus de 681 280 tokens.

Pas d'attaque, mais une leçon pour l'IA mutualisée

Selon Cloudflare, les requêtes en cause correspondent, par leur rythme et leur volume, à un usage normal de textes longs, et rien ne montre une exploitation volontaire. Le 9 septembre, le modèle a été retiré à 14 h, puis rétabli à 19 h 40 (heure UTC). Sa réserve de mémoire est passée à environ 2,04 millions de tokens, soit à peu près le double de la longueur maximale, et SGLang a été corrigé. Le correctif a été intégré au projet libre dans sa version 0.5.20 (18 septembre), puis complété dans les versions 0.5.21 (2 octobre) et 0.5.22 (19 octobre).

L'incident montre que, dans un service d'IA partagé, des clients qui ne se connaissent pas utilisent les mêmes machines et la même mémoire. Une simple erreur de configuration peut y produire une fuite, sans le moindre attaquant.

Que vérifier ?

Si vous avez utilisé GLM-5.3 sur Workers AI entre le 27 août et le 9 septembre, vos requêtes ont pu apparaître dans la réponse d'un autre client. Si vous lui envoyiez de très longs textes, vous avez pu recevoir des données d'autrui. Dans les deux cas, interrogez Cloudflare. Aux entreprises qui hébergent elles-mêmes des modèles avec SGLang en mode séparé (lecture et rédaction sur des machines distinctes), Cloudflare recommande :

• de passer à SGLang 0.5.22 ou plus récent, qui rejette les requêtes trop longues avant tout transfert ;
• de comparer, au démarrage de chaque machine, la taille de la réserve de mémoire à la longueur de texte maximale, et de refaire cette vérification après tout changement de modèle ou de réglages mémoire ;
• d'activer les contrôles d'intégrité de la mémoire (--disaggregation-enable-kv-checksum et --kv-canary) quand le modèle le permet.

Une question reste ouverte : les clients dont les requêtes ont circulé ont-ils été prévenus ? Le récit de Cloudflare n'en dit rien.