Cloudflare corrige une fuite de données inter-requêtes dans le moteur d'inférence GLM-5.3

Cloudflare a révélé un incident de sécurité concernant sa plateforme Workers AI, où le modèle GLM-5.3 a accidentellement renvoyé des données provenant des requêtes d'autres utilisateurs. La vulnérabilité, active du 27 août au 9 septembre 2026, a affecté 155 réponses et a été déclenchée par des prompts spécifiques à contexte long. Cloudflare a depuis corrigé le moteur d'inférence sous-jacent et restauré le modèle avec des vérifications de sécurité renforcées.

Ce qui s'est passé

Le 8 septembre 2026, le chercheur en sécurité Gadi Evron a signalé que le modèle @cf/zai-org/glm-5.3 sur Workers AI fuitait des données de session. Cloudflare a reproduit le problème le lendemain matin et a mis le modèle hors ligne en moins de 40 minutes. L'enquête a révélé qu'entre le 27 août et le 9 septembre, un petit nombre de clients ont reçu des réponses contenant du texte issu des requêtes d'autres clients effectuées sur le même modèle peu avant les leurs. Les 155 réponses affectées ont toutes été générées à partir de prompts dépassant 681 280 jetons. Cloudflare n'a trouvé aucune preuve d'une exploitation délibérée, notant que les motifs de requête correspondaient à une utilisation ordinaire de contextes longs plutôt qu'à des attaques ciblées.

La cause racine était une combinaison d'une erreur de configuration et d'un bug dans SGLang, le moteur d'inférence open source alimentant le service. Cloudflare avait déployé GLM-5.3 avec une fenêtre de contexte de 1 048 576 jetons, mais le pool de cache Key-Value (KV) sur les GPU de préremplissage ne pouvait contenir que 681 280 jetons. Bien que l'équipe soit consciente de cette incompatibilité, elle supposait que le moteur retournerait une erreur pour les prompts qui ne tenaient pas. Au lieu de cela, le moteur a tenté de traiter la requête via une voie de rejet défaillante, entraînant l'exposition. Aucun autre modèle hébergé sur Workers AI n'a été affecté car leurs pools KV étaient plus grands que leurs longueurs de contexte respectives.

Comment cela fonctionne

Workers AI sert GLM-5.3 en utilisant une architecture désagrégée où les GPU de préremplissage traitent les prompts et génèrent des caches KV, qui sont ensuite transférés via accès direct à la mémoire à distance (RDMA) vers les GPU de décodage pour la génération de réponse. Le cache KV est stocké dans un pool partagé de pages de taille fixe dans la mémoire GPU. Pour maintenir des performances élevées, ces pages ne sont pas remises à zéro entre les requêtes ; le moteur repose sur un suivi strict de la propriété pour garantir qu'une nouvelle requête écrase toute donnée précédente dans ses pages assignées.

Lorsqu'un prompt dépassait la taille du pool KV, le planificateur SGLang marquait la requête comme rejetée mais la remplaçait par un espace réservé d'un seul jeton pour lui permettre de traverser la mécanique de lotissement. Dans une configuration mono-nœud, cela aurait entraîné une erreur. Cependant, dans la configuration désagrégée, les files d'attente d'admission vérifiaient si une requête était « terminée » plutôt que « rejetée ». Comme la requête rejetée n'était pas marquée comme terminée, elle a été admise sur le nœud de préremplissage. Le nœud de préremplissage a généré un cache pour l'espace réservé d'un seul jeton et l'a transféré au nœud de décodage. Le nœud de décodage, attendant un transfert complet, a conservé les pages réservées restantes qui contenaient encore des données obsolètes d'utilisateurs précédents. Par conséquent, la réponse finale incluait du texte cohérent généré à partir de l'espace réservé mélangé aux données fuitées des pages de cache obsolètes.

Détails clés

• Modèle affecté : Seul @cf/zai-org/glm-5.3 a été impacté ; tous les autres modèles Workers AI sont restés sécurisés.
• Fenêtre d'exposition : La vulnérabilité était présente du 27 août 2026 jusqu'à ce que le modèle soit mis hors ligne le 9 septembre 2026.
• Portée de l'impact : Exactement 155 réponses ont été affectées, toutes provenant de prompts plus longs que 681 280 jetons.
• Cause racine : Une incompatibilité entre la fenêtre de contexte de 1 048 576 jetons et le pool de cache KV de 681 280 jetons, combinée à un bug dans la gestion des requêtes rejetées par SGLang en mode désagrégé.
• Remédiation : Cloudflare a augmenté la taille du pool KV à environ 2,04 millions de jetons et a corrigé SGLang pour interrompre correctement les requêtes rejetées avant le transfert KV.
• Corrections en amont : Les mainteneurs de SGLang ont fusionné plusieurs correctifs, notamment les PR #38704 et #38935, et ont publié les versions v0.5.21 et v0.5.22 pour résoudre le problème pour tous les utilisateurs.

Pourquoi c'est important

Cet incident met en lumière la fragilité de la sécurité mémoire dans les moteurs d'inférence LLM haute performance. Alors que les fournisseurs poussent vers des fenêtres de contexte plus grandes et un débit plus rapide, ils adoptent souvent des architectures complexes comme le préremplissage et le décodage désagrégés. Ces systèmes reposent sur une gestion précise de l'état à travers plusieurs nœuds. Lorsque les valeurs de configuration telles que la longueur de contexte et la taille du pool mémoire ne sont pas strictement appliquées, les cas limites peuvent entraîner de graves vulnérabilités de sécurité. Pour les équipes d'ingénierie construisant sur ces plateformes, cela souligne l'importance de comprendre que les optimisations de performance comme la réutilisation de mémoire non remise à zéro impliquent une responsabilité significative pour le fournisseur d'infrastructure.

Pour les développeurs utilisant Workers AI ou des services similaires, cet événement rappelle que l'isolation des locataires n'est pas seulement une préoccupation au niveau réseau, mais aussi un défi de gestion de la mémoire au sein du moteur d'inférence lui-même. Bien que la réponse rapide de Cloudflare ait limité l'exposition, le fait que 155 utilisateurs aient reçu des données fuitées indique que même de brèves fenêtres de vulnérabilité peuvent avoir des conséquences tangibles. Cela démontre également la valeur de la divulgation coordonnée et de la collaboration open source, car les correctifs développés par Cloudflare ont été fusionnés en amont pour bénéficier à la communauté SGLang plus large.

Ce que vous pouvez faire

• Mettre à jour SGLang : Si vous exploitez votre propre infrastructure d'inférence utilisant SGLang, passez immédiatement à la version v0.5.22 ou ultérieure pour intégrer les derniers correctifs de sécurité.
• Valider les configurations : Assurez-vous que la taille de votre pool de cache KV est strictement supérieure à la longueur de contexte maximale pour chaque modèle que vous déployez. Ne comptez pas sur le moteur pour gérer gracieusement les incompatibilités.
• Surveiller les anomalies : Implémentez la journalisation et la surveillance des temps de réponse et des compteurs de jetons. Des réponses arrivant inopinément rapidement pour des prompts longs peuvent indiquer un traitement tronqué ou des erreurs de cache.
• Examiner les configurations désagrégées : Si vous utilisez des architectures de préremplissage/décodage désagrégées, vérifiez que les voies de rejet sont correctement gérées à travers les nœuds et que les requêtes rejetées ne procèdent pas au transfert KV.
• Vérifier les problèmes en amont : Consultez régulièrement les traqueurs de problèmes des moteurs d'inférence dont vous dépendez, tels que SGLang, pour connaître les bugs connus de sécurité mémoire et les conditions de course.
• Auditer l'utilisation de contextes longs : Si votre application repose sur des fenêtres de contexte très longues, effectuez des tests d'intégration spécifiques qui valident la cohérence de la sortie et l'isolation sous charge, plutôt que de simplement vérifier les codes de statut HTTP.