Fuite du cache KV chez Cloudflare : l'isolation IA mise à l'épreuve

2026-10-28 · 5 min de lecture · Cybersécurité

Le 26 octobre 2026, Cloudflare a révélé que 155 réponses de son modèle GLM-5.3 sur Workers AI contenaient des données d'autres clients, à cause d'un cache KV mal dimensionné. Voici ce que l'incident enseigne sur l'isolation des services d'inférence IA et les obligations de la Loi 25.

Une fuite de cache KV (Key-Value cache) est un défaut d'isolation dans lequel un service d'inférence IA réutilise, pour un client, des calculs intermédiaires produits pour la requête d'un autre client. Le 26 octobre 2026, Cloudflare a divulgué un tel incident sur sa plateforme Workers AI : entre le 27 août et le 9 septembre 2026, 155 réponses du modèle GLM-5.3 ont contenu des fragments de requêtes et de générations appartenant à d'autres utilisateurs.

Le cache KV est la mémoire de travail d'un LLM (Large Language Model) : il conserve les représentations des jetons (tokens) déjà lus pour éviter de les recalculer. Sur une plateforme mutualisée, des centaines de clients partagent les mêmes processeurs graphiques (GPU, Graphics Processing Units). L'étanchéité entre leurs requêtes repose donc entièrement sur la gestion de cette mémoire par le logiciel de service, ici le moteur libre SGLang.

Que s'est-il passé sur le modèle GLM-5.3 de Workers AI ?

Selon le billet technique publié par Cloudflare le 26 octobre 2026, deux défauts se sont combinés. Le modèle annonçait une fenêtre de contexte de 1 048 576 jetons, alors que la réserve de cache KV des GPU de préremplissage (prefill) ne pouvait en contenir que 681 280. Par ailleurs, un bogue de SGLang n'interrompait pas correctement les requêtes trop longues : le nœud de décodage recevait un signal de transfert terminé et lisait des données périmées laissées par des requêtes précédentes.

Le chercheur Gadi Evron, de la firme Knostic, a signalé le problème le 8 septembre 2026 par le programme de primes aux bogues HackerOne de Cloudflare. Le modèle a été rendu privé puis rétabli le 9 septembre 2026 avec une configuration corrigée. Cloudflare précise qu'aucun autre modèle de Workers AI n'était touché et dit n'avoir trouvé aucune trace d'exploitation délibérée : le volume et le calendrier correspondaient à un usage ordinaire de contextes longs.

Pourquoi cet incident concerne-t-il les entreprises québécoises ?

Toute entreprise qui envoie des contrats, des courriels de clients ou du code source à une API (Application Programming Interface) d'inférence mutualisée dépend de l'étanchéité du fournisseur. Ce risque figure dans le Top 10 2025 de l'OWASP pour les applications de LLM, sous la catégorie LLM02, divulgation d'informations sensibles.

Au Québec, la Loi sur la protection des renseignements personnels dans le secteur privé (LPRPSP) encadre directement ce scénario. L'article 18.3 exige un contrat écrit précisant les mesures de protection imposées au prestataire, qui doit aviser sans délai l'entreprise de toute violation. L'article 3.5 oblige l'entreprise à aviser la CAI (Commission d'accès à l'information) et les personnes concernées si l'incident présente un risque de préjudice sérieux. L'enjeu prolonge l'analyse du risque fournisseur IA publiée sur ce blogue le 27 octobre 2026.

Les 5 vérifications à mener auprès de vos fournisseurs d'inférence IA

Inventorier les modèles mutualisés utilisés : dresser la liste des API d'inférence (Workers AI, Bedrock, Vertex AI, Azure AI Foundry, OpenRouter) appelées par vos équipes et vos applications.
Exiger une clause d'avis d'incident : conformément à l'article 18.3 de la LPRPSP, le contrat doit fixer un délai d'avis et le contenu attendu (période, modèles, volume de réponses touchées).
Demander le mode d'isolation : le fournisseur doit expliquer comment il sépare les caches entre clients, s'il partage des préfixes de requêtes et s'il propose des instances dédiées pour les données sensibles.
Vérifier l'alignement des limites annoncées : une fenêtre de contexte annoncée supérieure à la capacité réelle de l'infrastructure, comme chez GLM-5.3, est un signal de configuration à interroger lors des appels d'offres.
Consigner l'incident au registre : le Règlement sur les incidents de confidentialité impose de tenir un registre de tous les incidents, même ceux sans risque de préjudice sérieux, et de le conserver cinq ans.

Comment réduire l'exposition dès novembre 2026 ?

Le cadre de profil IA générative du NIST (NIST AI 600-1, juillet 2024) recommande de classer les données selon leur sensibilité avant tout envoi à un modèle externe. Concrètement, trois gestes réduisent le risque : retirer les renseignements personnels des requêtes envoyées aux services mutualisés, réserver les données confidentielles à des instances dédiées ou hébergées au Canada, et journaliser les réponses inattendues signalées par les utilisateurs. Une réponse contenant un texte étranger à la requête doit être traitée comme un incident potentiel, et non comme une simple hallucination.

Questions fréquentes

Qu'est-ce qu'une fuite de cache KV dans un modèle d'IA ?

Une fuite de cache KV survient lorsqu'un service d'inférence réutilise, pour une requête, des données de travail produites pour la requête d'un autre utilisateur. Le modèle génère alors une réponse contenant des fragments étrangers. En octobre 2026, Cloudflare a confirmé 155 réponses de ce type sur son modèle GLM-5.3, entre le 27 août et le 9 septembre 2026.

Les clients de Cloudflare Workers AI doivent-ils agir ?

Les clients ayant utilisé le modèle GLM-5.3 entre le 27 août et le 9 septembre 2026 devraient vérifier quelles données ils lui ont transmises et quelles réponses inhabituelles ils ont reçues. Cloudflare indique qu'aucun autre modèle n'était touché. Une entreprise québécoise doit inscrire l'événement à son registre si des renseignements personnels étaient en cause.

Un incident chez un fournisseur d'IA doit-il être déclaré à la CAI ?

Oui, si des renseignements personnels détenus par l'entreprise sont touchés et que l'incident présente un risque de préjudice sérieux. L'article 3.5 de la LPRPSP impose alors d'aviser la CAI et les personnes concernées. L'entreprise reste responsable des renseignements confiés à son prestataire, d'où l'importance d'une clause d'avis rapide dans le contrat.

Comment éviter qu'un service d'IA mutualisé expose nos données ?

La mesure la plus efficace consiste à ne pas envoyer de données sensibles aux services mutualisés. Pour les cas d'usage confidentiels, une instance dédiée ou un modèle hébergé dans votre propre environnement supprime le partage de mémoire entre clients. Le contrat doit aussi préciser les mesures d'isolation et le délai d'avis d'incident du fournisseur.

Sources

Cloudflare, « Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang » (26 octobre 2026) : https://blog.cloudflare.com/kv-cache-exposure-remediation/
GIGAZINE, « Cloudflare explains KV cache leakage between requests in the GLM-5.3 Workers AI model » (28 octobre 2026) : https://gigazine.net/gsc_news/en/20261028-kv-cache-exposure-remediation/
LégisQuébec, Loi sur la protection des renseignements personnels dans le secteur privé, RLRQ c. P-39.1, articles 3.5 et 18.3 : https://www.legisquebec.gouv.qc.ca/fr/document/lc/P-39.1
LégisQuébec, Règlement sur les incidents de confidentialité, RLRQ c. P-39.1, r. 3.1 : https://www.legisquebec.gouv.qc.ca/fr/document/rc/P-39.1,%20r.%203.1
OWASP, « LLM02:2025 Sensitive Information Disclosure », Top 10 for LLM Applications 2025 : https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/
NIST, AI 600-1, « Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile » (juillet 2024) : https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf

Voir tous les articles