29 octobre 2026 | Cybersécurité, intelligence artificielle
Imaginez un hôtel d'un millier de chambres.
Chaque client se voit attribuer sa propre chambre. Après son départ, une femme de chambre change le linge, range les affaires et prépare les lieux pour le visiteur suivant.
Mais un jour, un dysfonctionnement se produit.
Le nouveau client ouvre l'armoire et y trouve les documents du résident précédent. Correspondance privée, notes professionnelles, et potentiellement des informations confidentielles.
Personne n'a crocheté la serrure. Personne n'a deviné le mot de passe.
Le système a simplement décrété que la chambre était prête, alors même qu'elle n'avait pas été nettoyée.
Le 26 octobre 2026, Cloudflare a révélé un incident similaire. À la différence près qu'au lieu d'un hôtel, il s'agissait d'une intelligence artificielle cloud, et au lieu d'une armoire, de la mémoire d'un processeur graphique.
Le réseau de neurones qui se souvenait d'autrui
Du 27 août au 9 septembre, le modèle GLM-5.3 a fonctionné au sein de la plateforme cloud Workers AI.
Il était utilisé pour le traitement de texte, la programmation et d'autres tâches.
Tout semblait normal, jusqu'à ce que le chercheur en sécurité Gadi Evron découvre un comportement étrange.
Parfois, le réseau de neurones répondait à la requête d'un utilisateur en y intégrant des fragments d'informations appartenant à un client totalement différent.
Cloudflare a ouvert une enquête et confirmé le problème.
Au total, l'entreprise a identifié 155 réponses impactées.
Précision importante : il s'agit de réponses et non nécessairement de 155 utilisateurs distincts. La société n'a trouvé aucune preuve d'une exploitation malveillante de cette faille par des attaquants.
Comment la mémoire d'une personne s'est retrouvée chez une autre
Pour qu'un réseau de neurones puisse fonctionner rapidement, il utilise un mécanisme spécial appelé cache KV.
Pour faire simple, il s'agit d'une mémoire de travail qui stocke les résultats intermédiaires du traitement du texte.
Cela évite au modèle de recalculer l'intégralité des informations précédentes lors de la génération de chaque nouveau mot.
Afin d'accélérer les opérations, les serveurs peuvent réutiliser des portions de mémoire vidéo une fois les requêtes terminées.
En soi, ce comportement est normal.
Le problème est né de la combinaison de deux erreurs.
Premièrement : le modèle était configuré pour traiter environ un million de jetons, mais la mémoire allouée ne suffisait que pour 681 000.
Deuxièmement : le moteur logiciel SGLang gérait mal les requêtes qui ne tenaient pas dans la mémoire.
Au lieu de rejeter correctement la requête, le système poursuivait son exécution.
Et lors de la génération de la réponse, il pouvait utiliser d'anciennes données restées en mémoire après le passage d'autres utilisateurs.
C'est ainsi que des informations tierces se retrouvaient piégées dans une nouvelle réponse.
Le plus grand danger : le système ne signalait aucune erreur
Cet incident comporte un détail que les développeurs feraient bien de garder en mémoire.
Le serveur renvoyait une réponse HTTP 200 standard, synonyme de succès.
Pour un système de monitoring, tout semblait fonctionner normalement.
Requête acceptée. Réponse générée. Aucune erreur.
Pourtant, le contenu de la réponse pouvait inclure les données d'un autre client.
Il apparaît donc insuffisant de se limiter à la vérification de la disponibilité des API et au succès des requêtes HTTP.
Un système peut formellement fonctionner correctement tout en compromettant la confidentialité au même moment.
Pourquoi cela compte pour les IA personnelles
Imaginons l'avenir, dans lequel chaque individu dispose de son propre assistant IA.
L'un aborde des sujets familiaux. Un autre charge un contrat commercial. Un troisième analyse du code source contenant des clés privées.
Extérieurement, chacun dispose de son espace personnel et de son propre historique de discussion.
Mais si tous ces assistants partagent un serveur d'inférence commun, la simple séparation des comptes utilisateurs ne suffit pas à garantir une isolation correcte de la mémoire de travail du modèle.
L'incident de Cloudflare a démontré qu'une faille peut survenir en amont de la couche application.
Pas dans la base de données, pas dans le système d'authentification, ni même dans la logique du chatbot lui-même.
Mais directement au cœur du mécanisme de traitement des requêtes sur le GPU.
Cela ne signifie pas que tous les réseaux de neurones dans le cloud divulguent des données tierces. Le problème identifié concernait un modèle et une configuration bien précis.
Néanmoins, les ingénieurs disposent désormais d'un scénario supplémentaire avéré qu'ils se doivent de prendre en compte.
La réaction des développeurs
Cloudflare a désactivé le modèle incriminé, corrigé la configuration de la mémoire et apporté des modifications à SGLang.
Désormais, les requêtes rejetées ne doivent plus continuer à être traitées comme si elles avaient passé les contrôles avec succès.
Des vérifications renforcées ont également été mises en place concernant le transfert et la réutilisation des données entre nœuds de calcul.
Il est recommandé aux développeurs utilisant SGLang de mettre à jour leur version vers la 0.5.22 ou une version corrective ultérieure.
Cependant, la leçon principale va bien au-delà d'un simple produit logiciel.
La nouvelle frontière de la sécurité numérique
Auparavant, nos principales craintes résidaient dans le vol d'un mot de passe par un pirate, l'intrusion dans une base de données ou l'interception du trafic réseau.
Une nouvelle question s'impose désormais.
Et si les données d'une personne finissaient entre les mains d'une autre non pas à cause d'un piratage, mais en raison d'une mauvaise gestion de la mémoire par l'intelligence artificielle ?
Au sein d'une infrastructure d'IA multi-tenant, l'isolation doit être garantie à tous les niveaux : du compte et de l'API jusqu'aux processus de calcul et à la mémoire des accélérateurs.
D'autant plus lorsque les réseaux de neurones obtiennent un accès direct à des documents, des messages personnels, des dépôts de code et des systèmes d'entreprise.
En guise de conclusion
L'incident de Cloudflare ne met pas en cause une cyberattaque de grande envergure avérée.
Il illustre quelque chose de tout aussi instructif : une véritable erreur d'ingénierie qui a brisé la barrière étanche entre les utilisateurs.
Ce type d'événement rappelle à quel point la sécurité liée à l'intelligence artificielle devient complexe.
Nous avons appris à sécuriser les connexions par le chiffrement. Nous avons appris à cloisonner l'accès aux bases de données.
Il nous reste désormais à protéger avec la même rigueur la mémoire des systèmes de calcul eux-mêmes.
Car une véritable IA personnelle ne doit pas seulement se souvenir de son propriétaire. Elle doit avoir la garantie absolue de ne jamais se remémorer celle d'autrui.
СТЕКЛЯННЫЙ МОСТ
Sources primaires
Cloudflare, 26 octobre 2026. Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang.
https://blog.cloudflare.com/kv-cache-exposure-remediation/
SGLang, projet open source de moteur d'inférence, correctifs et historique de développement.