La fuite de données IA de Cloudflare a exposé une faille que les seules autorisations utilisateur ne pouvaient pas empêcher. Certains clients authentifiés ont reçu des réponses IA contenant des informations issues des requêtes d’autres clients, sans avoir besoin d’accéder à leurs identifiants de connexion.
Dans un avis publié le 26 oct., Cloudflare a confirmé que 155 réponses de son modèle GLM-5.3 sur Workers AI contenaient des informations provenant d’autres clients entre le 27 août et le 9 sept. 2026. La défaillance s’est produite au sein de l’infrastructure d’inférence IA partagée, où les dispositifs de protection censés isoler les charges de travail des clients ont cessé de fonctionner correctement.
Comment la fuite de données IA de Cloudflare s’est produite
Le chercheur en sécurité Gadi Evron, de Knostic, a signalé la vulnérabilité via HackerOne le 8 sept. Cloudflare a reproduit le problème le lendemain matin et désactivé temporairement le modèle concerné, selon son rapport d’incident.
Le problème concernait SGLang, le moteur d’inférence open source qui exécute GLM-5.3. Cloudflare avait configuré une fenêtre de contexte de 1 048 576 jetons, mais le cache clé-valeur (KV) du GPU ne pouvait en contenir que 681 280. Ce cache stocke temporairement les informations utilisées pendant le traitement par l’IA.
Les requêtes trop volumineuses auraient dû renvoyer des erreurs. Au lieu de cela, un bug logiciel permettait aux requêtes rejetées de poursuivre leur chemin dans le pipeline d’inférence distribué, où la génération des réponses pouvait puiser dans des données mises en cache provenant de requêtes antérieures.
Dans son enquête indépendante, Knostic a documenté des réponses contenant des noms, des informations de facturation, des éléments de code source, des chemins de système de fichiers et des enregistrements d’agents IA. Ces informations présentent des risques de confidentialité pour les entreprises qui utilisent l’IA dans le développement logiciel et d’autres flux de travail sensibles.
Cloudflare a déclaré que GLM-5.3 était le seul modèle de Workers AI touché et n’a trouvé aucune preuve d’une exploitation délibérée. Le service a été rétabli le 9 sept. après la correction de la configuration et l’application d’un correctif au moteur.
Un avis de sécurité SGLang documente les correctifs associés et les recommandations propres au déploiement.
Pourquoi les contrôles d’accès n’ont pas pu empêcher l’exposition
La défaillance s’est produite sous la couche de gestion des identités et des accès. Les contrôles d’identité des agents IA d’entreprise limitent l’accès et les autorisations déléguées, mais ne peuvent pas garantir à eux seuls l’isolation de la mémoire au sein d’une infrastructure d’inférence partagée.
La nécessité de tester l’isolation s’applique également aux plateformes d’entreprise proposant des modèles IA partagés. Broadcom affirme que VMware Cloud Foundation prend en charge la séparation des données propre à chaque locataire, bien que sa documentation publiée n’établisse pas comment ces protections se comparent aux dispositifs de protection de la mémoire d’inférence concernés par l’incident de Cloudflare.
L’incident de Cloudflare se distingue également de l’exposition de données traitée par les contrôles de protection des données IA de Microsoft, qui contribuent à empêcher les informations sensibles d’atteindre des destinations IA non fiables. Ici, les informations ont franchi les frontières entre clients après l’arrivée des requêtes dans un service autorisé.
Ce qu’a découvert eWeek : des contrôles d’API réussis n’ont pas détecté une défaillance d’isolation
La configuration de Cloudflare a exposé un écart mesurable entre la longueur de contexte acceptée et la mémoire disponible. La limite de 1 048 576 jetons dépassait de 367 296 jetons la capacité du cache de préremplissage, soit environ 54 % de plus que ce que le cache pouvait contenir.
Les ingénieurs connaissaient cette incompatibilité avant le lancement, mais s’attendaient à ce que les requêtes trop volumineuses échouent sans risque. Les tests de référence réalisés avant le lancement renvoyaient des réponses HTTP positives sans vérifier l’intégrité du contenu généré. Les tests ultérieurs de Knostic ont démontré que ces réponses pouvaient contenir des informations sans rapport appartenant à d’autres clients.
Cloudflare a ensuite corrigé l’incompatibilité de capacité, corrigé le traitement des requêtes et ajouté des contrôles directs du déploiement. Ces changements ont traité la défaillance signalée sans établir que toutes les vulnérabilités potentielles liées à l’isolation de la mémoire avaient été éliminées.
Les évaluations de sécurité des entreprises devraient donc examiner comment les fournisseurs vérifient la propriété des caches, rejettent les requêtes trop volumineuses et testent l’isolation dans des conditions de défaillance. Cloudflare a corrigé l’exposition signalée, mais les informations publiées ne permettent pas d’établir dans quelle mesure des configurations vulnérables comparables ont été déployées ailleurs.
Envie d’en savoir plus sur les astuces, les trucs et les techniques de prompting liés à l’IA ? Laissez-nous vous apprendre Comment parler à l’IA gratuitement ! Suivez notre cours de six minutes à The Neuron Academy, notre plateforme d’apprentissage pratique conçue pour aider les professionnels à utiliser l’IA avec davantage d’assurance au travail.
Apprenez quelques méthodes simples pour rédiger de meilleurs prompts et obtenir des résultats plus utiles avec l’IA, ou explorez gratuitement notre autre cours consacré à l’IA pendant sept jours. Les lecteurs d’eWeek bénéficient de sept jours d’accès gratuit. Découvrez toutes les leçons ici →