Votre LLM peut renvoyer un 200 OK avec les données de quelqu'un d'autre : Cloudflare et ChatGPT ont fuité des données de cette manière

Votre LLM peut renvoyer un 200 OK avec les données de quelqu'un d'autre : Cloudflare et ChatGPT ont fuité des données de cette manière

🔎 Le pire bug de 2026 ne renvoie aucune erreur

Selon une analyse publiée par Towards AI le 4 novembre 2026, des API LLM ont renvoyé des réponses en HTTP 200 contenant les données d'autres utilisateurs. Deux incidents documentés, deux acteurs majeurs : Cloudflare et ChatGPT. Le point commun n'est pas le modèle. C'est l'infrastructure de serving.

Le détail qui glace : rien n'a « planté ». Pas de code 500, pas de timeout, pas d'alerte dans les dashboards. Le code de statut affirmait que tout allait bien. Le contenu, lui, appartenait à quelqu'un d'autre.

Pourquoi maintenant ? Parce que la course aux fenêtres de contexte d'un million de tokens — devenue le standard marketing des modèles frontière comme Gemini 3.1 Pro ou GPT-5.5 — a imposé des architectures préfill/decode désagrégées avec des caches KV partagés. La performance a créé la surface d'incident. Et personne n'avait prévu le cas où les deux se mélangent.

L'essentiel

• Des API LLM ont renvoyé des HTTP 200 avec des données cross-tenant : le contenu d'autres utilisateurs, dans une réponse « réussie » (Towards AI, 4 novembre 2026, relayé par LLM Marketcap).
• Cause racine côté runtime : une fenêtre de contexte annoncée à 1 048 576 tokens, mais un pool de KV cache en préfill limité à 681 280 tokens. Un bug du mode préfill/decode désagrégé laissait le handoff continuer au lieu de renvoyer une erreur.
• Le nœud de décode lisait alors des pages de cache obsolètes laissées par des requêtes antérieures — et produisait une réponse fluide, plausible, et étrangère.
• GeoCache (arXiv) propose une défense élégante contre l'extraction du cache : rotation des clés par un opérateur spécifique à la session, inconnu de l'attaquant.
• Une checklist en cinq points pour tout opérateur d'API qui expose un LLM, détaillée plus bas.

Outils recommandés

Si vous opérez ou auditez une infrastructure LLM, voici la boîte à outils minimale pour appliquer la checklist de cet article.

Que s'est-il passé : des 200 OK truffés de données étrangères

Selon Towards AI (4 novembre 2026), deux incidents distincts — l'un impliquant Cloudflare, l'autre ChatGPT — partagent la même signature : une réponse HTTP 200, donc traitée comme valide, dont le contenu provient d'autres utilisateurs de la plateforme.

« Cross-tenant » signifie que la cloison entre locataires d'une même infrastructure a sauté. Votre requête, votre session, votre facturation — mais la réponse de quelqu'un d'autre. Fragments de conversations, contextes métier, données personnelles : ce qui devait rester cloisonné ressort par la grande porte.

Un breach classique laisse des traces : une requête anormale, un volume sortant, une exfiltration. Ici, la donnée fuit dans une réponse parfaitement formelle, journalisée comme un succès, potentiellement mise en cache, affichée, stockée, voire réinjectée dans des pipelines en aval. La forensique commence avec un handicap majeur : le système croit que tout s'est bien passé.

Juridiquement, c'est le scénario type de la violation de données personnelles au sens de l'article 33 du RGPD : notification à l'autorité de contrôle sous 72 heures, information des personnes concernées. Peu importe que la fuite soit un « bug ». La donnée a circulé entre locataires.

Précision d'honnêteté journalistique : la publication ne détaille pas l'ampleur exacte de chaque incident — nombre de requêtes touchées, durée, catégories de données. Ce flou est en soi un enseignement. Une fuite qui ressemble à un succès peut durer longtemps sans que personne ne la cherche.

Le mécanisme : quand le handoff préfill/decode se passe dans le noir

Le bug n'est pas dans le modèle ni dans le prompt : il est dans l'orchestration du serving, au moment précis où la requête passe du préfill au décode.

Rappel mécanique. Le préfill traite tout le prompt d'un coup et produit le KV cache — les tenseurs d'attention qui « mémorisent » le contexte. Le décode génère les tokens un par un en s'appuyant sur ce cache. Pour la performance, les stacks modernes désagrègent ces deux phases sur des nœuds GPU distincts, et transfèrent le cache de l'un à l'autre.

Le KV cache, c'est littéralement la mémoire de travail du modèle — cette recherche sur la mémoire de travail des LLM montre à quel point cette mémoire conditionne le raisonnement. Ici, c'est elle qui a fuité.

Dans les incidents décrits, le runtime annonçait une fenêtre de contexte de 1 048 576 tokens (2^20, le chiffre rond du marketing), mais le pool de KV cache alloué au préfill n'était que de 681 280 tokens — environ 65 % de la promesse. Tout prompt dont la taille tombait dans la zone entre les deux, entre 681 280 et 1 048 576 tokens, devrait être rejeté explicitement.

C'est là que le bug intervient. Au lieu de renvoyer une erreur, le mode préfill/decode désagrégé laissait la requête poursuivre son handoff. Le nœud de décode lisait alors des pages de cache obsolètes — laissées par des requêtes antérieures, d'autres locataires — et générait à partir de ce matériau. Résultat : HTTP 200, contenu étranger.

Le pire ? La réponse est fluide, cohérente, plausible. Ce n'est pas du bruit : c'est du vrai texte issu de vraies conversations. Sans canary ni contrôle de provenance, un client ne peut pas la distinguer d'une réponse légitime.

Multi-tenance et cache partagé : une bombe structurelle, pas un accident

Si ce bug a pu exister, c'est parce que l'économie entière du serving LLM repose sur le partage agressif de ressources.

Les GPU coûtent cher, les requêtes explosent, donc les plateformes multiplexent des milliers de locataires sur des pools partagés. Et pour économiser du calcul, les caches réutilisent les pages : le prefix caching, qui reconnaît un préfixe déjà traité pour éviter de le recalculer, est vendu comme une optimisation majeure. Latence divisée, coûts réduits.

Mais une ressource partagée est un domaine de défaillance partagé. La réutilisation du cache, c'est comme un hôtel qui ne change pas les draps : tant que le ménage est fiable, tout va vite et bien. Le jour où le ménage saute une étape, le client suivant dort dans la chambre du précédent — avec sa correspondance ouverte sur la table.

La course aux contextes géants aggrave mécaniquement le risque. Plus la fenêtre annoncée est grande, plus le cache doit être massif, plus la pression sur le pool est forte, plus les heuristiques de réutilisation et d'éviction deviennent complexes. Un million de tokens, c'est aussi un million d'occasions de se tromper de page.

Point crucial : ici, aucun attaquant n'est nécessaire. Un bug d'orchestration suffit. C'est ce qui distingue cet incident des attaques d'extraction volontaire du cache — qui existent aussi, et auxquelles répond GeoCache. Les deux menaces partagent la même racine : le cache est une surface exposée, pas un détail d'implémentation.

GeoCache : rendre l'extraction du cache mathématiquement aveugle

Face aux attaques d'extraction cross-requête, GeoCache (arXiv) applique une idée simple : rotater les clés de cache de la victime avec un opérateur spécifique à la session, inconnu de l'attaquant.

Le scénario d'attaque visé : un adversaire sonde le cache avec des prompts candidats, mesure la similarité cosinus pour détecter les correspondances, et reconstitue progressivement le contenu des requêtes des autres. Une attaque par canal auxiliaire, patiente et silencieuse.

Avec la rotation, tous les candidats produits par l'attaquant affichent une similarité cosinus proche de zéro avec les clés rotées. Le bon candidat devient indistinguable d'un prompt sans rapport : le signal que l'attaquant cherche à lire n'existe plus. L'attaque ne devient pas plus difficile — elle devient aveugle.

Précision importante : GeoCache neutralise l'extraction volontaire du cache. Elle ne remplace pas la correction du bug de handoff décrit plus haut, qui est un défaut du runtime, pas un canal auxiliaire. Les deux défenses sont complémentaires — et la checklist qui suit couvre les deux.

La checklist de défense pour une API qui expose un LLM

Cinq mesures, toutes implémentables immédiatement, qui auraient bloqué les incidents décrits par Towards AI.

1. Isolez le KV cache par tenant et par requête. Aucune page de cache ne doit être réutilisable au-delà de son périmètre sans garantie explicite. Si vous activez le prefix caching, qu'il soit cloisonné par locataire, avec des namespaces vérifiés — pas supposés.

2. Validez les limites de contexte au handoff préfill/decode. Si le prompt dépasse le pool réel, échouez explicitement : 413, 5xx, message clair. Jamais de dégradation silencieuse. L'écart entre la fenêtre annoncée (1 048 576 tokens) et le pool réel (681 280 tokens) doit produire une erreur, pas une zone grise.

3. Quota et pagination des réponses. Limitez la taille de ce qui peut sortir d'une seule réponse. Un attaquant — ou un bug — qui ne peut extraire que des fragments paginés et plafonnés voit son blast radius réduit d'autant.

4. Détectez les injections de prompt côté sortie. Filtrer l'entrée ne suffit pas : scannez ce que le modèle renvoie. L'affaire du prompt adware qui transformait Codex en panneau publicitaire l'a démontré : la sortie d'un LLM est un vecteur d'attaque à part entière.

5. Testez la contamination cross-tenant dans la CI du serving. Des requêtes canari avec des payloads marqueurs, émises depuis plusieurs locataires sur la même infrastructure, avec une assertion binaire : aucun marqueur ne doit apparaître hors de sa session. Si ce test n'existe pas dans votre CI, votre isolation est une croyance, pas une propriété.

Vous consommez une API LLM : le plan côté client

Vous ne pouvez pas corriger le runtime de votre fournisseur. Vous pouvez détecter la contamination, limiter les dégâts, et choisir vos batailles.

Première ligne de défense : le canari par session. Injectez un marqueur unique dans chaque session, journalisez chaque réponse, et alertez si un marqueur étranger apparaît.

Concrètement, l'approche tient en trois gestes. Générez d'abord un marqueur unique et imprévisible par session — par exemple un préfixe CANARY- suivi d'une chaîne hexadécimale aléatoire — et placez-le au début de chaque prompt envoyé au fournisseur. Journalisez ensuite l'intégralité des réponses reçues dans un log brut, sans filtrage ni écrasement. Enfin, faites analyser ces logs par une règle simple : si un marqueur canari autre que celui de la session courante apparaît dans une réponse, une contamination cross-tenant est suspectée, et l'alerte doit partir immédiatement. La détection est binaire et ne demande aucun outil sophistiqué — une simple recherche de motif sur les journaux suffit. Un canari hors de sa session n'est pas une curiosité à investiguer plus tard : c'est un incident.

Deuxième ligne : traitez toute sortie de LLM comme une entrée non fiable. C'est encore plus critique avec les agents. Quand vous codez depuis votre téléphone pendant que Codex travaille sur votre machine, une réponse contaminée ne reste pas sur l'écran : elle devient des commandes exécutées chez vous. Le choix du modèle pour ces charges compte d'autant plus — notre comparatif des LLM pour agents détaille les options.

Troisième ligne : classez vos données avant de les envoyer. La sensibilité de ce qui transite par ces API grimpe en flèche — ChatGPT gère désormais les finances personnelles des abonnés Pro. Quand le LLM voit vos transactions bancaires, une fuite cross-tenant n'est plus un incident technique : c'est un incident de données financières personnelles.

Quatrième ligne, pour les charges vraiment sensibles : sortez de la multi-tenance. Un modèle à poids ouverts auto-hébergé — DeepSeek V4 Pro, Kimi K2.6 ou GLM-5.1 — est mono-locataire par construction : pas de cache partagé, pas de voisin. Notre guide pour installer un LLM en local et notre sélection des meilleurs LLM locaux sont le point de départ ; pour expérimenter, un petit modèle sur un VPS (Hostinger) suffit avant d'investir dans du GPU.

Enfin, posez la question à vos fournisseurs, noir sur blanc : comment isolez-vous le KV cache entre locataires ? Que se passe-t-il quand un prompt dépasse le pool réel ? Un vendeur qui répond « nous réutilisons le cache pour la performance » sans jamais prononcer le mot « isolation » vient de vous donner sa réponse.

❌ Erreurs courantes

Erreur 1 : considérer un 200 OK comme une preuve d'intégrité

Le statut HTTP mesure le transport, pas la véracité du contenu. Les incidents décrits sont passés inaperçus précisément parce que tout le monitoring était au vert. La solution : des contrôles au niveau du contenu — canaris, détection de PII inattendue, vérification de cohérence entre la question et la réponse.

Erreur 2 : désactiver le cache « pour la sécurité »

Couper le prefix caching en bloc détruit la latence et les coûts pour un gain de sécurité mal ciblé. La bonne réponse est l'isolation par tenant et la rotation des clés à la GeoCache, pas l'abandon d'une optimisation qui fait tourner l'économie du serving.

Erreur 3 : ne tester que la couche applicative

Les équipes testent les injections de prompt dans l'application et jamais le serving. Or le bug documenté par Towards AI vivait sous la couche application, dans le handoff préfill/decode. Les tests de contamination cross-tenant doivent vivre dans la CI de l'infrastructure, pas seulement dans celle du produit.

❓ Questions fréquentes

Mes données ont-elles pu fuiter si j'utilise ChatGPT ou Cloudflare ?

C'est possible si vos requêtes sont passées par les points d'entrée concernés pendant la période du bug. Le mécanisme documenté par Towards AI implique que des réponses ont pu contenir des fragments d'autres sessions. L'ampleur exacte par fournisseur reste floue : surveillez les communications d'incident et exigez des réponses écrites.

Tous les fournisseurs de LLM sont-ils concernés ?

Non, mais toute stack cumulant les trois facteurs de risque l'est potentiellement : préfill/decode désagrégé, KV cache partagé entre requêtes, et dégradation silencieuse au handoff. Un fournisseur mono-tenant ou sans réutilisation de cache n'a pas cette surface. Posez les trois questions, par écrit.

Faut-il arrêter d'envoyer des données sensibles aux API LLM ?

Non, mais tissez vos données. Classez-les : ce qui est public peut partir chez n'importe quel fournisseur, ce qui est sensible exige des garanties d'isolation contractuelles, des canaris de détection — ou un auto-hébergement. Le tout-en-tout et le tout-dehors sont les deux mauvaises réponses.

L'auto-hébergement supprime-t-il le risque ?

Il supprime le risque cross-tenant par construction : un seul locataire, pas de voisin dans le cache. Mais vous héritez des bugs du runtime que vous faites tourner — le même type de défaut de handoff peut exister dans votre stack. Auto-hébergé ne veut pas dire sans risque : cela veut dire responsable.

Comment détecter une contamination dans mes propres systèmes ?

Trois signaux : un canari étranger dans vos réponses, des identifiants ou de la PII que vous n'avez jamais envoyés, une réponse sémantiquement déconnectée du prompt. Journalisez tout, conservez les logs bruts, et alertez sur les écarts. Sans logs bruts, aucune forensique n'est possible après coup.

✅ Conclusion

Le 200 OK contaminé par accident est le cauchemar parfait de l'ère LLM : un bug qui fuit des données sans jamais ressembler à une erreur — et la checklist ci-dessus (isolation du KV cache, échec explicite au handoff, canaris en CI) est le minimum vital pour toute API qui expose un modèle. Si vous choisissez un fournisseur ce mois-ci, commencez par notre comparatif des meilleurs LLM — et posez la question du KV cache avant de poser celle du prix.