En bref
- Entre le 27 août et le 9 septembre 2026, 155 réponses de GLM 5.3 ont contenu des données issues de requêtes clientes antérieures.
- Le problème exigeait des demandes dépassant 681 280 jetons, alors que le modèle annonçait une capacité maximale de 1 048 576 jetons.
- Cloudflare attribue l'exposition à la combinaison d'un réglage incohérent et d'un défaut de SGLang dans son fonctionnement réparti.
- L'analyse des requêtes n'a révélé aucun signe d'exploitation volontaire, mais elle ne précise pas la nature des données exposées.
Une fuite cantonnée aux requêtes les plus longues
Cloudflare a rendu publique une défaillance d'isolation entre clients sur GLM 5.3, un modèle de génération de texte conçu par Z.ai. Le service Workers AI permettait à plusieurs clients d'utiliser ce modèle sur l'infrastructure de Cloudflare. Durant cette période, certaines réponses ont intégré des éléments provenant de demandes envoyées peu auparavant par d'autres utilisateurs. L'entreprise a recensé 155 réponses touchées entre le 27 août et le 9 septembre 2026. Elle a publié son analyse le 26 octobre dans le cadre d'une divulgation coordonnée.
Pour les clients concernés, la conséquence était directe: une réponse pouvait révéler des fragments appartenant à une autre session. Toutes les demandes affectées dépassaient 681 280 jetons, unités utilisées par le modèle pour découper et traiter un texte. Cloudflare affirme qu'aucun autre modèle de Workers AI n'a subi cette exposition. L'incident restait donc circonscrit à GLM 5.3 et à des contextes exceptionnellement longs. Le rapport ne détaille toutefois pas la nature des informations apparues dans ces réponses.
Le signalement qui a déclenché l'enquête
Le chercheur Gadi Evron, de Knostic, a signalé le comportement le 8 septembre par HackerOne, une plateforme de remontée de failles. Son rapport indiquait que de très longues demandes recevaient parfois du texte provenant de sessions étrangères. Cloudflare a commencé ses vérifications le lendemain. Deux comptes indépendants ont permis à son équipe de reproduire la fuite en moins de vingt-cinq minutes. Cette reproduction a confirmé que le défaut franchissait bien la séparation attendue entre deux clients.
L'entreprise a déclaré un incident le 9 septembre à 13 h 22, en temps universel coordonné. Elle a rendu le modèle privé trente-huit minutes plus tard, ce qui faisait échouer les nouvelles demandes. La cause principale a été identifiée à 14 h 35. Après modification du réglage et du moteur, GLM 5.3 est redevenu public à 19 h 40. Cloudflare avait alors testé les changements avec le script du chercheur et ses propres marqueurs de détection.
Deux défauts ont ouvert le passage entre les clients
La première cause venait d'un écart de capacité connu avant le lancement. GLM 5.3 acceptait théoriquement 1 048 576 jetons, mais la mémoire de préparation ne pouvait en conserver que 681 280. Cette mémoire, appelée cache KV, garde les informations nécessaires pour relier chaque nouveau mot au texte déjà traité. Cloudflare pensait que SGLang, le moteur logiciel libre exécutant le modèle, refuserait proprement toute demande trop longue. Aucun contrôle n'imposait pourtant une correspondance entre la capacité annoncée et la mémoire réellement disponible.
Les essais préalables avaient surtout vérifié les codes de réponse et les performances, pas la cohérence du texte produit. Ils retournaient un succès apparent, ce qui a conforté cette interprétation erronée. Le second défaut se trouvait dans SGLang lorsque préparation et génération fonctionnaient sur des machines distinctes. Une demande trop grande était marquée comme rejetée, mais poursuivait malgré tout son trajet avec un contenu provisoire d'un seul jeton. Le client recevait finalement une réponse réussie plutôt que l'erreur prévue.
Des pages anciennes lues comme si elles étaient nouvelles
Dans cette architecture répartie, des processeurs graphiques préparent la demande, puis transmettent son cache à d'autres processeurs chargés de produire la réponse. Le transfert utilise un accès direct à la mémoire distante, ou RDMA, qui copie les données entre machines. Le nœud de génération réservait assez de pages mémoire pour la demande complète. Il recevait ensuite un message lui annonçant que le transfert était terminé. Il supposait donc que chaque page réservée contenait les informations de la requête en cours.
En réalité, la demande rejetée n'avait remplacé qu'une seule page avec son jeton provisoire. Les autres pages contenaient encore des informations laissées par des requêtes précédentes, car elles ne sont pas effacées entre deux usages. Le nœud de génération les a néanmoins considérées comme appartenant à la nouvelle demande. Il a alors composé une réponse cohérente à partir d'un mélange, sans produire l'erreur attendue. Selon Cloudflare, chaque requête franchissant le seuil suivait ce chemin défectueux.
Une méthode concluante, mais un périmètre encore incomplet
L'observation initiale reposait sur un script reproductible fourni par le chercheur. Cloudflare a ensuite comparé deux comptes, déployé un nœud de test corrigé et utilisé des marqueurs témoins pour repérer d'éventuels mélanges. La configuration finale porte la capacité du cache de préparation à environ 2,04 millions de jetons. L'entreprise a aussi modifié SGLang afin qu'une demande rejetée s'arrête avant toute réservation ou transmission de mémoire. Cette double correction traite donc le réglage fautif et le comportement dangereux du moteur.
L'interprétation de Cloudflare repose également sur le calendrier et le volume des demandes enregistrées. Après retrait de ses propres tests et de ceux du chercheur, l'entreprise les juge compatibles avec un usage ordinaire de longs contextes. Elle ne voit donc aucun indice d'exploitation délibérée. Cette conclusion ne décrit toutefois ni le contenu exact exposé, ni le nombre de clients concernés, ni les données éventuellement conservées par leurs systèmes. Elle signifie seulement que les traces examinées ne montrent pas d'abus répété.
Les correctifs dépassent désormais ce cas précis. Cloudflare a appliqué des contrôles de capacité et plusieurs protections à tous ses déploiements SGLang, tandis que les mainteneurs ont publié des corrections successives. Certaines vérifications d'intégrité ne couvrent cependant pas encore toutes les architectures de modèles. Le travail se poursuit sur des contrôles à chaque lecture mémoire et sur la vérification formelle du protocole de transfert. Cette méthode cherche à démontrer les propriétés de sécurité du système, mais Cloudflare reconnaît que des lacunes pourront subsister.
Ce qui reste à confirmer
Le rapport chiffre 155 réponses affectées, mais ne donne ni le nombre de clients concernés, ni la nature ou la sensibilité des données apparues. L'absence d'indice d'exploitation volontaire repose sur l'analyse du calendrier et du volume des requêtes identifiées. Certaines protections d'intégrité restent en développement ou ne couvrent pas encore GLM 5.3 et toutes les architectures.
