L'essentiel
La CVE-2026-59822 est une faille d'authentification de sévérité élevée (CVSS 8,8) dans l'endpoint MCP Streamable HTTP de LiteLLM ; l'agence américaine CISA l'a inscrite début septembre 2026 à son catalogue des vulnérabilités activement exploitées (KEV), avec une échéance de correctif au 16 septembre. Avant LiteLLM 1.84.0, un attaquant non authentifié pouvait envoyer un en-tête Authorization forgé qui déclenchait un repli OAuth2 passthrough, remplaçait la vérification de clé échouée par un objet d'authentification vide et atteignait ainsi les outils branchés sur la passerelle via le Model Context Protocol. La parade : passer en 1.84.0 et verrouiller l'endpoint. Si vous placez vos modèles derrière une passerelle LLM dans le cadre d'une intégration d'IA générative, corrigez maintenant – et traitez-la comme une infrastructure de production, pas comme un service annexe.
Ce que fait concrètement la CVE-2026-59822
LiteLLM, édité par BerriAI, est l'une des passerelles IA open source les plus déployées : un proxy qui offre aux équipes une API unique compatible OpenAI devant des dizaines de fournisseurs de modèles, avec gestion des clés, budgets, routage et journalisation au même endroit. Les versions récentes parlent aussi le Model Context Protocol (MCP), le standard émergent qui permet à un LLM d'appeler des outils et des sources de données externes. La CVE-2026-59822 se loge précisément à cette jonction – l'endpoint MCP Streamable HTTP – et elle est notée 8,8 (élevée) sur l'échelle CVSS.
Le mécanisme est un cas d'école de repli d'authentification mal conçu. Dans les versions de LiteLLM antérieures à la 1.84.0, une requête vers l'endpoint MCP portant un en-tête Authorization forgé échouait bien à la validation normale de la clé, mais au lieu d'être rejetée, elle basculait vers un chemin OAuth2 passthrough. Ce chemin remplaçait la vérification échouée par un objet utilisateur authentifié vide : la requête était considérée comme valide et poursuivait sa route. Résultat : un appelant non authentifié, muni d'un simple jeton Bearer arbitraire, pouvait ouvrir une session MCP authentifiée, énumérer les outils exposés par la passerelle, les appeler et atteindre tous les services en aval auxquels ils sont branchés.
La CISA n'inscrit pas une faille au catalogue KEV sur une hypothèse : il faut des preuves d'exploitation active. La CVE-2026-59822 faisait partie des sept vulnérabilités ajoutées début septembre 2026, avec une échéance de remédiation au 16 septembre pour les agences civiles fédérales américaines. Le lot se distingue par sa composition : trois des sept ajouts visaient l'infrastructure IA, et non les habituels VPN, serveurs de messagerie et applications web. C'est le signal à retenir : la tuyauterie IA est devenue une catégorie ordinaire d'infrastructure exploitée, et une échéance de correctif ferme sur la passerelle LLM d'une entreprise en est la conséquence directe.
Pourquoi la passerelle IA est la cible
On serait tenté de classer l'affaire comme « une CVE de plus », mais l'emplacement compte davantage que le mécanisme. Une passerelle IA n'est pas un service périphérique : c'est un point de passage obligé qui concentre les pouvoirs. Pour remplir son rôle, elle stocke les clés API de tous les fournisseurs de modèles, porte les budgets et règles de routage de toute l'organisation et, dès que MCP est activé, arbitre l'accès aux outils et aux sources de données que les modèles ont le droit de toucher. Compromettre la passerelle, ce n'est pas pirater une application : c'est atteindre les identifiants et la surface d'outils de tout ce qui transite par elle.
MCP aggrave le constat. Le protocole existe pour qu'un LLM puisse lister et invoquer des outils – une requête en base de données, un client d'API interne, un lecteur de fichiers – et chacun de ces outils est une porte vers un système réel. Un contournement d'authentification sur l'endpoint MCP ne signifie donc pas « un attaquant peut discuter avec votre modèle », mais « un attaquant peut appeler les outils que votre modèle peut appeler », avec les droits qui leur ont été accordés. Pour les équipes qui développent des agents IA, tout est là : c'est dans la couche d'outils que résident la capacité d'action réelle d'un agent – et son rayon d'impact. Une faille qui livre cette couche à un appelant anonyme s'apparente davantage à un compte de service volé qu'à un prompt divulgué.
Ce que cela change pour les équipes aux États-Unis et dans l'UE
D'abord, vérifiez si vous utilisez LiteLLM et dans quelle version. Parce qu'une passerelle LLM se monte en quelques minutes, elle arrive souvent sans responsable désigné – un POC monté par l'équipe data, un conteneur dans un namespace de plateforme, une dépendance d'un produit IA plus large. Tout déploiement antérieur à la 1.84.0 exposant l'endpoint MCP est concerné. Passez en 1.84.0 ou ultérieure et vérifiez-le comme pour toute entrée du KEV : avec un inventaire, pas avec un espoir. L'échéance fédérale du 16 septembre constitue un objectif interne raisonnable, même sans obligation de conformité.
Ensuite, cessez de considérer la passerelle IA comme une commodité : c'est de l'infrastructure. Les endpoints MCP et d'administration ne doivent pas être joignables depuis des réseaux non maîtrisés et doivent se trouver derrière une authentification et des contrôles réseau réels, plutôt que de reposer sur la seule vérification de clé de la passerelle – cette faille rappelle qu'un contrôle applicatif unique peut échouer en mode ouvert. Appliquez le moindre privilège à chaque connexion d'outil MCP pour qu'un contournement réussi atteigne le moins de choses possible, et faites tourner les clés fournisseurs stockées dans la passerelle si une exposition ne peut être exclue. Dans un contexte réglementé – un produit FinTech ou HealthTech dont les outils touchent des données clients – un accès non authentifié à cet outillage devient vite un incident à déclarer.
Enfin, intégrez l'infrastructure IA au même rythme de correctifs que le reste de votre stack. Quand trois des sept ajouts au KEV sont des composants IA, la leçon est claire : passerelles, serveurs d'orchestration et frameworks d'agents sont attaqués comme n'importe quel service exposé. Maintenir LiteLLM et ses équivalents à une ou deux versions de la dernière publication, et suivre leurs versions dans votre gestion des vulnérabilités, transforme la prochaine CVE d'infrastructure IA en simple mise à jour plutôt qu'en branle-bas de combat.
Quelles conséquences pour le marché français ?
En France, les passerelles LLM de type LiteLLM servent souvent à faire cohabiter plusieurs fournisseurs – y compris des modèles européens comme ceux de Mistral AI ou des modèles auto-hébergés – pour des raisons de souveraineté et de maîtrise des coûts. La passerelle devient alors le point de jonction entre applications métier, modèles et systèmes internes, souvent déployée par une équipe data sans être inscrite à la cartographie du SI.
Côté obligations, le cadre est connu : si un attaquant atteint des données personnelles via un outil MCP, la violation doit être notifiée à la CNIL dans les 72 heures (article 33 du RGPD). Les acteurs financiers relèvent en outre du règlement européen DORA pour la déclaration des incidents TIC majeurs. Côté veille, le CERT-FR de l'ANSSI publie régulièrement avis et alertes sur les vulnérabilités activement exploitées : c'est la source à suivre en parallèle du catalogue KEV. Pour les ESN, éditeurs et équipes produit françaises, la conséquence pratique est simple : la passerelle IA doit entrer dans la cartographie du SI, dans le processus de gestion des correctifs et dans le périmètre des audits de sécurité.
La checklist de la semaine
- Inventorier les passerelles. Repérer chaque déploiement LiteLLM – y compris les instances « fantômes » de POC et de namespaces de plateforme – et noter sa version et son responsable.
- Passer en 1.84.0+. Corriger toute version antérieure exposant l'endpoint MCP Streamable HTTP et vérifier le respect de l'échéance du 16 septembre.
- Fermer l'endpoint. Placer les endpoints MCP et d'administration derrière des contrôles réseau et une authentification forte ; aucune exposition à des réseaux non maîtrisés.
- Moindre privilège pour les outils. Passer en revue ce que chaque outil MCP connecté peut atteindre et le réduire au strict minimum.
- Rotation et revue. Faire tourner les clés API fournisseurs stockées dans la passerelle si une exposition ne peut être exclue, analyser les journaux à la recherche de requêtes à l'en-tête Authorization malformé sur la route MCP et préparer, le cas échéant, la notification CNIL.
- Intégrer l'infra IA au rythme. Suivre les versions des passerelles et frameworks dans la gestion des vulnérabilités pour que la prochaine CVE soit une routine.
Questions fréquentes
Qu'est-ce que la CVE-2026-59822 dans LiteLLM ?
La CVE-2026-59822 est une vulnérabilité d'authentification de l'endpoint MCP (Model Context Protocol) Streamable HTTP de LiteLLM, la passerelle et proxy IA open source de BerriAI. Elle est notée 8,8 (élevée) sur l'échelle CVSS. Avant la version 1.84.0, un attaquant non authentifié pouvait envoyer un en-tête Authorization forgé qui déclenchait un repli OAuth2 passthrough. Ce chemin remplaçait la vérification de clé échouée par un objet d'authentification vide, si bien que la requête atteignait les outils MCP sans clé LiteLLM valide. L'attaquant pouvait alors lister et appeler les outils configurés et accéder aux services qui y sont reliés.
Quelles versions de LiteLLM sont concernées et comment corriger ?
La faille touche les versions de LiteLLM antérieures à la 1.84.0 qui exposent l'endpoint MCP Streamable HTTP. Le correctif consiste à passer en LiteLLM 1.84.0 ou ultérieure. Il faut aussi rendre les endpoints MCP et d'administration inaccessibles depuis des réseaux non maîtrisés, inventorier les droits de chaque outil MCP connecté et rechercher dans les journaux les requêtes portant un en-tête Authorization inattendu ou malformé.
Pourquoi une faille de passerelle IA au catalogue KEV est-elle si grave ?
La CISA n'inscrit une vulnérabilité à son catalogue Known Exploited Vulnerabilities que si elle dispose de preuves d'exploitation active. L'inscription impose une échéance de correctif aux agences fédérales américaines, que les entreprises européennes ont tout intérêt à traiter comme un signal fort. La CVE-2026-59822 faisait partie des sept failles ajoutées début septembre 2026, dont trois visaient l'infrastructure IA : passerelles, serveurs d'orchestration et outils MCP sont désormais une cible ordinaire.
Comment sécuriser LiteLLM et les endpoints MCP ?
Traiter la passerelle IA comme une infrastructure de production : la corriger à un rythme régulier, rester à une ou deux versions de la dernière publication, placer chaque endpoint MCP et d'administration derrière des contrôles réseau et une authentification forte plutôt que de compter sur la seule vérification de clé de la passerelle. Appliquer le moindre privilège à chaque outil MCP, faire tourner les clés API des fournisseurs stockées dans la passerelle et intégrer ses versions au processus de gestion des vulnérabilités.
Sources
CISA – Known Exploited Vulnerabilities Catalog (source primaire, ajout début septembre 2026)
The Hacker News – CISA Adds Seven Exploited Flaws as Attackers Deploy Reverse Shells and Crypto Miners (septembre 2026)
GitLab Advisory Database – CVE-2026-59822 : LiteLLM MCP Authentication Bypass via OAuth2 Passthrough Fallback