Cloudflare : GLM-5.3 a renvoyé des données d’autres clients

Un modèle précis et une période passée

Cloudflare dit avoir identifié 155 réponses contenant des données de requêtes d’autres clients, envoyées peu auparavant au même modèle. Les réponses concernées suivaient des demandes de plus de 681 280 jetons. Le modèle est @cf/zai-org/glm-5.3 sur Workers AI : ce périmètre ne désigne ni tous les modèles GLM chez tous les hébergeurs, ni tous les services Cloudflare.

Selon l’opérateur, l’exposition a commencé au lancement du modèle le 27 août. Après le signalement d’un chercheur le 8 septembre, Cloudflare l’a retiré de l’accès public, a corrigé la configuration et le moteur, puis l’a rétabli le 9 septembre. La publication du rapport le 26 octobre n’annonce donc pas le début d’une fuite encore ouverte.

Cloudflare affirme qu’aucun autre modèle de Workers AI n’était affecté et dit ne pas avoir trouvé de preuve d’exploitation délibérée. Ces conclusions sont celles de son enquête. Elles ne signifient ni qu’aucune donnée n’a circulé, ni que SecuFocus a audité l’infrastructure.

La réponse pouvait être cohérente et venir du mauvais contexte

Le moteur SGLang prépare les requêtes sur un groupe de GPU et produit les réponses sur un autre. Son cache KV conserve en mémoire des informations calculées à partir du contexte. Dans ce déploiement, le cache de préparation était plus petit que la fenêtre de contexte annoncée.

Une demande trop longue aurait dû être rejetée. À la place, une erreur de transmission entre les deux groupes laissait le moteur de réponse lire des pages de cache contenant encore des données de requêtes précédentes. Le client pouvait recevoir un HTTP 200 et un texte cohérent. Cela ne prouvait pas que la réponse utilisait uniquement son propre contexte.

Ce mécanisme concerne l’isolement des données pendant l’inférence. Exclure les conversations de l’entraînement n’aurait pas corrigé ce défaut de mémoire.

Retrouver son usage avant de conclure pour son compte

Si votre application utilisait ce modèle sur cette période, retrouvez son identifiant dans la configuration et les journaux disponibles. Examinez ensuite les catégories de données transmises : documents internes, données personnelles ou secrets éventuels. Ne recopiez pas ces contenus dans une nouvelle demande à une IA pour lui faire diagnostiquer la fuite.

Demandez au support Cloudflare une évaluation propre à votre compte et conservez les éléments utiles à votre suivi d’incident. Le seuil de longueur des réponses concernées ne permet pas, à lui seul, de déclarer vos données non exposées : le rapport décrit aussi des données provenant de requêtes antérieures. Si des secrets ont été envoyés, faites décider leur révocation ou leur rotation selon cette évaluation.

Changer un modèle aujourd’hui ne retire pas une donnée qui aurait déjà été divulguée. Pour les prochains envois, limitez le contenu aux informations nécessaires et vérifiez le fournisseur réellement utilisé par l’application.

• Réduire les données confiées à une IA↗

Pour un hébergeur SGLang, contrôler aussi les erreurs et les interruptions

Cloudflare recommande aux opérateurs utilisant SGLang en mode de préparation et de génération séparées de passer à 0.5.22 ou ultérieur, ou de reprendre les correctifs nécessaires. Il demande aussi de comparer la taille réelle des caches à la longueur de contexte sur chaque groupe de GPU après les changements de modèle ou de configuration. Ce sont les recommandations de cet opérateur, pas un test de paquet réalisé par SecuFocus.

Le rapport insiste sur la libération différée des pages, les transferts et les requêtes interrompues. Les contrôles de corruption ne prennent pas encore en charge toutes les architectures de modèles. Installer une version sans contrôler la configuration active ne suffit donc pas à démontrer l’isolement de votre service.

• Ce qui reste à maintenir quand on héberge soi-même↗