La première CVE MCP de la liste KEV a atteint sa date limite fédérale : LiteLLM et le coffre de clés par défaut

CVE-2026-59822 est une elusion d'authentification dans le proxy LiteLLM de BerriAI — la passerelle open source qui achemine le trafic entre les applications et plus de 100 fournisseurs de modèles — et elle a atteint sa date limite fédérale de remédiation le 16 septembre 2026. La CISA a ajouté la faille à son catalogue des Known Exploited Vulnerabilities le 2 septembre avec une échéance fixée à aujourd'hui au titre de la BOD 26-04, en faisant la première implémentation de Model Context Protocol jamais inscrite comme activement exploitée par une autorité nationale de gestion des vulnérabilités (NVD ; The Hacker News). L'exploitation n'est pas théorique : l'infrastructure honeypot de Wiz a observé CVE-2026-59822 utilisée in the wild le 7 juillet — 56 jours avant l'inscription à la liste KEV (Wiz). Et la CVE n'est même pas la façon la plus courante d'entrer dans ces passerelles. Le scan de Wiz de février 2026 sur 3 074 instances LiteLLM exposées à Internet a trouvé 294 — 9,6 % — acceptant la clé maîtresse d'exemple sk-1234 imprimée dans la documentation même de LiteLLM, et 191 sans aucune authentification configurée (Wiz ; The Hacker News).

Cet article couvre quatre choses qu'un directeur d'ingénierie ou un responsable de plateforme doit savoir avant que la prochaine audit ne découvre une instance LiteLLM sur son réseau : comment fonctionne la elusion en une seule requête, pourquoi la clé maîtresse fait de la passerelle un coffre de credentials cloud, ce qu'exige réellement l'échéance KEV, et les six points de vérification qui referment l'exposition — plus le pattern de code à bannir de chaque gestionnaire d'authentification MCP que vous possédez.

Points clés

• CVE-2026-59822 est la première CVE spécifique à MCP sur la liste KEV de la CISA — ajoutée le 2 septembre 2026 avec une date limite fédérale de remédiation au 16 septembre 2026, à CVSS 8.8, et affectant toutes les versions de LiteLLM antérieures à 1.84.0.
• Le honeypot de Wiz a observé l'exploitation le 7 juillet 2026 — 56 jours avant l'inscription à la liste KEV — avec un token Bearer d'un seul caractère établissant une session MCP entièrement authentifiée.
• 294 des 3 074 passerelles LiteLLM exposées à Internet (9,6 %) acceptent la clé maîtresse d'exemple documentée sk-1234 ou aucune authentification — dont 191 n'exigent aucun credential, selon le scan Shodan de Wiz de février 2026.
• La clé maîtresse est un coffre de credentials cloud : un administrateur valide (ou un attaquant détenteur de la clé) peut utiliser le routage pass-through pour lire les métadonnées d'instances AWS et récupérer des credentials IAM, et IMDSv2 ne l'arrête pas car le proxy transmet les en-têtes préfixés x-pass-.
• La elusion est un pattern de code, pas seulement un bug : intercepter une authentification échouée et substituer un objet d'authentification vide. La recherche « Puppet » publiée dans ACM montre que cette classe de confus deputy atteint 90,89 % de succès de détournement de sélection d'outils tout en restant invisible pour MCP-Scan et McpSafetyScanner.

L'horloge de 24 heures, et comment la elusion fonctionne en une requête

La chronologie importe parce qu'elle montre que l'exploitation a couru devant la réponse fédérale à chaque étape. Wiz a rapporté la vulnérabilité aux mainteneurs de LiteLLM le 18 février 2026 ; le correctif est arrivé dans LiteLLM 1.84.0 le 25 avril ; le honeypot de Wiz a enregistré une exploitation réelle le 7 juillet ; la faille a été publiée le 8 juillet ; la CISA l'a ajoutée au catalogue KEV le 2 septembre — et a fixé l'échéance de remédiation 14 jours plus tard (Wiz ; NVD).

Le mécanisme est un fallback fail-open dans l'endpoint MCP de LiteLLM. L'endpoint supporte deux patterns d'authentification : les clés natives LiteLLM et les tokens OAuth2 transmis à un serveur MCP amont. Quand un token Bearer échoue à la validation de clé LiteLLM avec un 401 ou 403, le handler est censé retransmettre le token en amont. À la place, il intercepte l'erreur et renvoie un objet UserAPIKeyAuth() vide — une session authentifiée sans identité derrière elle (Wiz ; base de données d'avis GitLab). La démonstration de Wiz a utilisé Authorization: Bearer *** — un seul caractère — et reçu HTTP 200 avec un mcp-session-id` valide.

Ce que cette session peut atteindre dépend entièrement de la configuration du déploiement. Une passerelle avec un outil de requête de base de données connecté remet à l'attaquant un accès de requête ; l'intégration GitHub remet des lectures de dépôts et la création d'issues ; les connecteurs de système de fichiers remettent un accès lecture-écriture. Le drapeau allow_all_keys documenté par LiteLLM — recommandé par LiteLLM lui-même pour des « utilitaires à faible risque » — rend chaque serveur MCP configuré atteignable par le credential vide que la elusion crée (Hive Security). Le rayon d'impact n'est pas le proxy. C'est chaque système que les serveurs MCP du proxy touchent.

Trois défaillances, une passerelle

La recherche de Wiz a mis au jour quatre problèmes distincts dans LiteLLM avec des préconditions différentes — les aplatir en une seule « chaîne magique » fausse à la fois la gravité et la réponse (Wiz) :

1. CVE-2026-59822 — la elusion d'authentification MCP. Sans authentification, une requête, versions antérieures à 1.84.0. Corrigée dans 1.84.0.
2. CVE-2026-59821 — exécution de code au niveau root via des guardrails personnalisés. L'endpoint d'enregistrement de guardrails transmettait du Python soumis par l'administrateur à exec() sans la sandbox (retrait des builtins, vérifications de motifs interdits) appliquée sur le chemin de test de l'UI. Wiz a observé du code s'exécutant en tant que root dans le conteneur du proxy. Corrigée dans 1.82.0-stable. Celle-ci exigeait un accès administrateur — mais combinée au mode de défaillance 3, elle devient effectivement pré-authentifiée.
3. Authentification par défaut ou absente. Le résultat du scan de 294 sur 3 074. Quand aucune clé maîtresse n'est configurée, LiteLLM accordait à chaque appelant un accès PROXY_ADMIN — un comportement de conception sans CVE, corrigé en même temps que CVE-2026-59821.
4. Routage pass-through vers les métadonnées cloud. Un administrateur authentifié peut pointer une route pass-through vers le service de métadonnées d'instances AWS et retransmettre l'en-tête de token de session IMDSv2 à travers le comportement de retrait de préfixe x-pass- du proxy. Wiz et LiteLLM classent cela comme un comportement administrateur intentionné — pas de CVE, pas de correctif. Mais dès qu'une clé maîtresse par défaut ou divulguée efface l'hypothèse que seuls des administrateurs de confiance détiennent la clé, cette capacité « intentionnée » devient le chemin qui mène de la compromission de l'application à celle du compte cloud (CSA).

L'empilement est l'histoire. LiteLLM détient les clés API de chaque fournisseur de modèle configuré — OpenAI, Anthropic, AWS Bedrock, Azure, Google Vertex AI — et environ un tiers des environnements cloud sondés exécutent un déploiement (CSA). La note de recherche de la CSA qualifie la configuration de clé maîtresse de « coffre de credentials cloud ». Le coffre a déjà été vidé une fois : dans une compromission divulguée publiquement en août 2026, un attaquant disposant d'exécution de code sur un hôte passerelle a lu les variables d'environnement du conteneur, récupéré la clé maîtresse et une chaîne de connexion à la base de données, et copié des enregistrements directement hors de la base PostgreSQL qui soutient la passerelle (CSA).

Une instance corrigée n'est pas une instance sûre. Une passerelle corrigée vers 1.84.0 qui répond encore à sk-1234 est compromise par quiconque connaît la valeur par défaut — c'est-à-dire tous ceux qui ont lu le README.

Ce qu'exige réellement l'inscription à la KEV

Le catalogue des Known Exploited Vulnerabilities n'est pas un classement de gravité. C'est une constatation d'exploitation active avec une horloge contraignante : au titre de la BOD 26-04, les agences civiles fédérales doivent appliquer les atténuations du fournisseur avant l'échéance ou cesser d'utiliser le produit, et les agences doivent traiter en priorité les instances exposées à Internet. L'échéance qui tombe aujourd'hui s'applique directement aux agences fédérales — mais son effet porte plus loin, car un nombre croissant de polices de cyberassurance et de questionnaires de risque fournisseurs référencent le catalogue KEV comme base (Tech Insider). Une instance non corrigée de CVE-2026-59822 est désormais une constatation d'audit pour toute organisation dont le régime de conformité hérite de la liste KEV, qu'elle soit ou non une agence fédérale.

Le jalon compte pour le protocole, pas seulement pour le produit. CVE-2026-42271 — l'injection de commandes de l'endpoint de test de LiteLLM, ajoutée à la KEV dans un lot antérieur — était adjacente à MCP. CVE-2026-59822 est spécifique à MCP : la surface exploitée est l'endpoint MCP Streamable HTTP et son gestionnaire d'authentification. La première vulnérabilité MCP avec un mandat fédéral de remédiation signale d'où viendront les suivantes. L'avis de menace d'UltraViolet Cyber compte plus de 40 CVE divulguées contre des implémentations MCP rien qu'en 2026 (UltraViolet Cyber), le scan Internet de Bitsight a trouvé environ 1 000 serveurs MCP exposés servant des inventaires d'outils complets sans autorisation (Bitsight), et Practical DevSecOps a mesuré 30–82 % des serveurs MCP publics portant des failles exploitables (Practical DevSecOps). La pile d'exposition derrière la première inscription KEV n'est pas une valeur aberrante. C'est la population.

Le diagramme ci-dessous comprime l'incident en une minute : la chronologie qui a couru devant la réponse fédérale, les quatre modes de défaillance qui partagent une passerelle, et les six points de vérification qui referment l'exposition.

Les six points de vérification

La checklist de durcissement MCP que l'article parent distille en 12 contrôles gagne à présent un supplément spécifique aux passerelles. Six points, chacun vérifiable en quelques minutes :

1. Échouer fermé, de façon prouvable. Envoyez Authorization: Bearer *** à l'endpoint /mcp/` de la passerelle. Une instance correctement configurée renvoie 401 ou 403. Une instance vulnérable renvoie 200 avec un ID de session. C'est le test de CVE-2026-59822, et il prend une requête.
2. Inventorier et corriger. Trouvez chaque instance LiteLLM — y compris les déploiements fantômes dans les stacks de développeurs — enregistrez sa version et le digest de son image, et épinglez une version stable actuelle. 1.84.0 a corrigé en premier CVE-2026-59822 ; 1.82.0-stable a corrigé CVE-2026-59821 ; des avis ultérieurs existent, donc ne figez sur aucun des deux minimums (Hive Security). Si une correction immédiate est impossible, l'atténuation provisoire de l'avis est de bloquer /mcp/ et les routes apparentes en périphérie.
3. Régénérer la clé maîtresse et tout ce qui se trouve derrière. Remplacez sk-1234 et toute clé réutilisée. Si une exposition ou un accès suspect est soupçonné, régénérez les credentials des fournisseurs de modèles, de la base de données, OAuth et des services connectés via MCP, et révoquez les sessions dérivées — la chaîne de compromission documentée montre une compromission de passerelle qui se cascade directement en fuite de clé fournisseur et en vidage de base de données (CSA).
4. Délimiter l'accès aux outils MCP. Retirez allow_all_keys des intégrations sensibles, séparez les outils de lecture des outils d'écriture, et exigez une autorisation par équipe. La elusion accorde tout ce que la session peut atteindre — la configuration des outils est le rayon d'impact.
5. Confiner le plan de contrôle. Retirez l'exposition publique sauf exigence explicite, refusez aux charges de travail l'accès aux services de métadonnées cloud, placez les destinations egress sur allowlist, et exécutez le conteneur en non-root sans montages privilégiés. IMDSv2 ne défend pas ce chemin, car le proxy peut effectuer lui-même la requête de token et transmettre les en-têtes (Wiz).
6. Chasser dans les logs avant qu'ils n'expirent. Relevez dans les logs du reverse-proxy et de LiteLLM les sessions /mcp/ authentifiées avec des tokens d'apparence bidon, les appels d'outils inattendus, les événements de création de guardrails et les changements de configuration pass-through. Corrélez avec les logs de processus, DNS et d'audit cloud — et préservez les preuves avant de redémarrer, car un redémarrage efface l'état en mémoire mais ne révoque pas un credential volé (Hive Security).

Les points 1 et 3 sont la priorité du jour de l'échéance : le premier prouve la vulnérabilité, le second referme l'exposition permanente qui survit à tout correctif.

Ce que cela signifie au-delà de LiteLLM

Deux patterns se généralisent, et les deux appartiennent à toute revue d'authentification MCP dorénavant.

Premier : les fallbacks fail-open sont une odeur de code, pas un bug de LiteLLM. La elusion tient en trois lignes — intercepter le 401, substituer un objet d'authentification vide, continuer. Tout proxy MCP qui délègue l'authentification à un fournisseur amont via un fallback passthrough porte la même classe. Le correctif est un standard de revue, pas un bump de version : quand la validation amont échoue, la requête se termine. Elle ne continue jamais avec une identité non authentifiée.

Second : les passerelles sont des plans de contrôle, et la recherche sur le confus deputy dit qu'elles défaillent à la couche métadonnées. La recherche « Puppet » publiée dans ACM a évalué des attaques de confus deputy sur 14 modèles sur 2 hôtes MCP et mesuré des taux de détournement de sélection d'outils jusqu'à 90,89 % et d'exécution de payload de bout en bout jusqu'à 86,46 % — tout en restant indétectable par MCP-Scan et McpSafetyScanner, architecturalement incapables de saisir une manipulation au niveau des métadonnées (ACM). Une passerelle qui concentre des credentials de modèles, la visibilité des prompts et l'accès aux outils derrière une seule frontière d'authentification concentre précisément ce que la AI Controls Matrix de la CSA signale pour les contrôles d'identité et de gestion des secrets (CSA). La traduction opérationnelle : authentifiez la passerelle comme un plan de contrôle et confinez-la comme une frontière de compromission — IAM au moindre privilège, pas de credentials par défaut, métadonnées inatteignables, egress sur allowlist.

Le contexte plus large est un protocole qui mûrit de « l'autorisation optionnelle » vers l'application fédérale. Le scan de décembre 2025 de Bitsight a trouvé environ 1 000 serveurs MCP exposés sans autorisation (Bitsight) ; l'analyse honeypot d'août 2026 de Wiz a documenté des campagnes actives visant LiteLLM, les serveurs MCP et les frameworks IA par RCE, injection de prompt aveugle et vol de credentials en mémoire (Wiz)) ; et une troisième elusion d'authentification de LiteLLM — CVE-2026-49468, une injection d'en-tête Host divulguée le 28 mai 2026 — complète un pattern 2026 où le même produit a livré trois défaillances d'authentification distinctes en un an (avis GitHub). L'inscription à la liste KEV est le point où ce pattern cesse d'être un sujet de recherche et devient une ligne de conformité.

La spécification MCP du 2026-07-28 a déplacé le protocole vers un cœur sans état et le travail d'autorisation de l'écosystème avance vers OAuth 2.1 avec des tokens liés à l'audience. L'architecture referme des classes entières de vulnérabilités. Mais l'incident LiteLLM prouve que la couche opérationnelle décide des issues : un déploiement sans état et conforme à la spécification qui accepte encore sa clé maîtresse d'exemple reste compromis. Corrigez la CVE, puis auditez les valeurs par défaut — dans cet ordre, avant la prochaine échéance.

Lectures connexes

• Checklist de durcissement de sécurité MCP : 1 467 serveurs exposés et les contrôles qui les referment — l'article parent : 12 contrôles de durcissement couvrant transport, authentification, enregistrement d'outils, runtime et audit, chacun vérifiable en moins de cinq minutes
• Le paradoxe MCP : pourquoi le sans-friction est fragile — l'analyse de risque au niveau protocole : pourquoi une norme qui rend l'intégration sans friction concentre en même temps le rayon d'impact de compromission
• MCP 2026-07-28 : ce que le protocole sans état signifie pour les déploiements d'agents B2B — le cœur de protocole sans état qui élimine les surfaces d'attaque d'état de session que cette classe de CVE exploite

---

Un distributeur de taille intermédiaire fait tourner un agent d'approvisionnement qui cote face à NetSuite, BigCommerce et trois catalogues de fournisseurs, avec une passerelle LiteLLM acheminant le trafic de modèles et exposant les outils MCP de l'agent. Une vérification en une requête contre /mcp/ prouve que la passerelle échoue fermée ; la clé maîtresse vient du gestionnaire de secrets, jamais du README ; le rôle IAM de la passerelle ne peut pas atteindre les métadonnées d'instance ; et les outils MCP que l'agent peut appeler sont délimités à la lecture des prix et l'écriture des devis — rien d'autre. Quand la prochaine inscription KEV tombera, la remédiation sera un bump de version, pas une enquête de compromission.

Demander une construction ciblée. Une semaine de découverte. Vous obtenez un inventaire système, une cartographie des flux et un périmètre fixe — que vous construisiez avec nous ou non.