La CISA ajoute le contournement d’authentification MCP de LiteLLM au KEV : n’importe quel jeton Bearer suffisait

Le 2 septembre 2026, l'Agence américaine de cybersécurité et de sécurité des infrastructures a ajouté CVE-2026-59822 à son catalogue des vulnérabilités exploitées connues sous l'intitulé « BerriAI LiteLLM Improper Authentication Vulnerability », l'une des sept failles du lot de ce jour-là. La faille se trouve dans le point de terminaison MCP Streamable HTTP de LiteLLM : lorsque la validation d'une clé LiteLLM échouait, le repli par passthrough OAuth2 substituait un objet UserAPIKeyAuth() vide au lieu de rejeter la requête, si bien que tout en-tête Authorization Bearer fabriqué ouvrait une session MCP authentifiée. Un attaquant qui atteignait ce point de terminaison pouvait lister et appeler tous les outils MCP avec lesquels la passerelle était configurée, et, par leur intermédiaire, atteindre les services situés derrière. Toutes les versions antérieures à 1.84.0 sont affectées, et les agences civiles fédérales disposaient jusqu'au 16 septembre pour remédier au problème. Cette fiche — l'inscription au catalogue KEV du contournement d'authentification MCP de LiteLLM — est une entrée parmi the OrcaRouter AI Incident Archive, qui contient l'ensemble complet des fiches ainsi que les entrées voisines de cet incident.

La raison pour laquelle un bug dans un proxy compte davantage que ne le suggère son score CVSS tient à ce qui se trouve derrière le proxy. L’équipe de recherche sur les menaces de Wiz le dit sans détour : « Un proxy LiteLLM peut détenir des clés pour chaque fournisseur de modèles vers lequel il effectue le routage, notamment OpenAI, Anthropic, Azure et Gemini. Il peut également fonctionner avec des autorisations IAM cloud et se connecter à des services internes via des serveurs d’outils MCP. Une seule compromission peut donner à un attaquant accès aux identifiants et aux services en aval du proxy, et pas seulement au proxy lui-même. » Wiz Research déclare avoir découvert la faille, et les honeypots de Wiz ont ensuite enregistré des tentatives d’exploitation.

Le mécanisme : une vérification échouée qui a renvoyé une session valide

L'avis de BerriAI lui-même, GHSA-7488-6r32-c95q, décrit le défaut en deux phrases : « Le gestionnaire d'authentification MCP prenait en charge le passthrough OAuth2 pour les serveurs MCP en amont, mais le chemin de repli pouvait remplacer une validation de clé LiteLLM ayant échoué par un objet UserAPIKeyAuth() vide. Cela permettait à des requêtes avec un en-tête Authorization fabriqué d'atteindre l'outillage MCP sans clé LiteLLM valide. » Le mot important est repli. Le code comportait une branche pour les déploiements qui transmettent directement le jeton OAuth d'un serveur MCP en amont, et lorsqu'une clé LiteLLM ne parvenait pas à être validée, cette branche renvoyait un objet d'authentification vide plutôt qu'une erreur.

Un objet d’authentification vide n’est pas équivalent à l’absence d’objet d’authentification. Le code en aval voyait un UserAPIKeyAuth construit avec succès et poursuivait, sans qu’aucun tenant, aucun utilisateur et aucune portée n’y soient attachés. L’analyse de Wiz est plus directe quant à la conséquence pratique : « lorsque la validation du jeton échoue, plutôt que de rejeter la requête, le serveur renvoie un objet UserAPIKeyAuth() vide sans aucune restriction. N’importe quel jeton Bearer (même un seul caractère, par ex. x) accorde un accès MCP complet. »

Ce que cela offre à un attaquant, c’est un menu. Le protocole MCP expose une liste d’outils, de sorte qu’une session qui s’authentifie renvoie les noms et les schémas de chaque outil que la passerelle a été configurée pour atteindre — bases de données, dépôts de code, API internes, dans les exemples de Wiz. L’avis du fournisseur énonce clairement l’effet : « Un attaquant pourrait utiliser cela pour lister et appeler les outils MCP configurés et accéder aux services connectés exposés via MCP. » Les appels d’outils s’exécutent ensuite avec l’autorité que le proxy lui-même détient à l’égard de ces backends, ce qui constitue le problème de concentration des identifiants décrit par Wiz.

Un correctif en mai, une CVE en juillet, une échéance fédérale en septembre

Les dates ne s’alignent pas comme un lecteur pourrait le supposer, et les écarts sont la partie intéressante. LiteLLM 1.84.0 — la première version que l’avis désigne comme corrigée — a été téléversée sur PyPI le 14 mai 2026, selon les métadonnées de publication de l’index des paquets. L’identifiant CVE a été réservé auprès du programme CVE le 7 juillet 2026 et l’enregistrement publié le lendemain, 8 juillet ; l’entrée OSV PYSEC-2026-3479 a suivi le 23 juillet. L’inscription KEV est intervenue le 2 septembre, avec une date limite de remédiation au 16 septembre.

Deux constats s’ensuivent. Premièrement, la version corrigée était publique depuis plus de trois mois avant que la CISA classe la faille comme exploitée — les organisations visées par l’échéance disposaient donc d’une mise à niveau fonctionnelle pendant tout ce temps, et l’ajout au KEV n’a pas marqué le moment où un correctif est apparu. Deuxièmement, l’écart entre les versions s’est creusé depuis : la version actuelle de LiteLLM sur PyPI est 1.106.5, mise en ligne le 27 octobre 2026. Un déploiement resté sur une version inférieure à 1.84.0 accuse désormais plus de vingt versions mineures de retard, et non plus simplement un correctif.

Ce que l’annonce établit, et ce qu’elle n’établit pas

L'alerte de la CISA concernant le lot indique que les ajouts sont effectués « sur la base de preuves d'une exploitation active », et l'entrée lisible par machine du catalogue pour CVE-2026-59822 comporte une date d'ajout au 2 septembre 2026, une date d'échéance au 16 septembre 2026, une valeur d'utilisation connue dans des campagnes de rançongiciel de « Unknown », et deux faiblesses : CWE-287 (authentification incorrecte) et CWE-306 (authentification manquante pour une fonction critique).

• Établi :La CISA a évalué la faille comme activement exploitée et l'a inscrite sur la liste fédérale de remédiation. L'enregistrement SSVC du NVD, attribué à un coordinateur de la CISA et horodaté du 2 septembre 2026, consigne l'exploitation comme « active », l'automatisabilité comme « oui » et l'impact technique comme « partiel ».

• Établi :Une exploitation a été observée dans un environnement contrôlé. Wiz a publié du trafic de honeypots montrant des requêtes avec des jetons d’un seul caractère sondant un point de terminaison d’énumération de modèles : une requête GET vers /v1/models portant « Authorization: Bearer x ». The Hacker News, qui rapportait le lot KEV le 3 septembre, a décrit la même activité en indiquant que Wiz observait « des efforts d’exploitation impliquant CVE-2026-59822 contre ses honeypots pour sonder les points de terminaison d’énumération de modèles ».

• Établi : les deux scores de gravité existent et diffèrent selon le référentiel. L’avis de BerriAI évalue la faille à 8,8 selon CVSS 4.0, gravité élevée, avec confidentialité élevée, intégrité faible et disponibilité nulle ; l’évaluation CVSS 3.1 de NIST, qui fait autorité dans le NVD, la situe à 8,2. Ces deux nombres décrivent le même défaut selon des systèmes de notation différents et ne doivent pas être comparés comme si l’un supplantait l’autre.

• Non établi :aucune victime nommée. Ni l'alerte de la CISA, ni l'avis de BerriAI, ni l'article de Wiz, ni la couverture de The Hacker News n'identifient une organisation dont les outils MCP auraient été atteints via cette faille, ou ne signalent des identifiants ou des données qui en auraient été dérobés. Le dossier public d'exploitation se compose de télémétrie de honeypot et d'une détermination fédérale, non d'une violation divulguée.

• Non établi : qu'aucun groupe de rançongiciels ne l'utilise. Le champ KEV affiche « Unknown », une valeur attribuée par la CISA, et non une conclusion d'absence dans un sens ou dans l'autre.

Le précédent de juin, et la chaîne d’exécution de code à distance que ce n’est pas

Il s'agit de la deuxième faille LiteLLM à atteindre le catalogue KEV en 2026, et la précédente est facile à confondre avec celle-ci. CVE-2026-42271, ajoutée le 8 juin 2026 avec une date limite au 22 juin, est une injection de commande dans les points de terminaison de test du serveur MCP de LiteLLM : Wiz décrit des points de terminaison qui permettent à un utilisateur de tester une configuration de serveur MCP avant de l'enregistrer, le champ command étant transmis à l'exécution d'un sous-processus sans validation. Des attaquants ont soumis une fausse configuration de serveur stdio dont la commande téléchargeait et exécutait un cryptomineur, et renvoyaient une poignée de main MCP d'apparence valide afin que le test semble réussir. L'entrée de la CISA pour cette faille répertorie CWE-78 et CWE-77 — injection de commande et d'arguments, et non authentification.

Cette faille est celle qui peut être chaînée. Wiz indique que CVE-2026-42271 « peut être chaînée avec un contournement de la validation de l'en-tête Host de Starlette (CVE-2026-48710) pour parvenir à une RCE totalement non authentifiée », et que des chercheurs externes ont relié le groupe de rançongiciels Qilin à l'exploitation active de cette chaîne. CVE-2026-48710 a été ajoutée au catalogue KEV dans le même lot du 2 septembre que le contournement LiteLLM, avec la même échéance du 16 septembre, et la note du catalogue de la CISA elle-même concernant la faille Starlette indique qu'elle pourrait être chaînée avec CVE-2026-42271. Le lien avec Qilin se rapporte à ce couplage. Il ne s'agit pas d'une conclusion concernant CVE-2026-59822, et rien dans les sources examinées ne relie le groupe de rançongiciels au contournement d'authentification.

Un détail administratif distingue les deux entrées LiteLLM : l’action requise de la liste de juin cite la BOD 22-01, la plus ancienne directive opérationnelle contraignante, tandis que la liste de septembre cite la BOD 26-04, « Prioritizing Security Updates Based on Risk ». L’alerte de la CISA n’explique pas ce changement, et le catalogue ne l’annote pas.

Qu’est-ce qui a changé après

Le chemin de remédiation est court. L'avis de BerriAI recommande de mettre à niveau vers la version 1.84.0 ou ultérieure et propose une solution de contournement aux équipes qui ne peuvent pas migrer immédiatement : « désactivez les routes MCP ou bloquez l'accès à /mcp/ et aux points de terminaison MCP associés au niveau de votre proxy inverse ou de votre passerelle API. » Cette solution de contournement est un instrument brutal — elle supprime la fonctionnalité plutôt que d'en restreindre l'accès — mais c'est la seule atténuation que le fournisseur cite pour les déploiements non corrigés.

Le texte d'action requise de la CISA pour les points d'entrée place les agences fédérales devant le même compromis : appliquer les mesures d'atténuation selon les instructions du fournisseur et conformément à la BOD 26-04, « ou cesser d'utiliser le produit si les mesures d'atténuation ne sont pas disponibles », chaque agence étant responsable d'évaluer l'exposition d'un actif à Internet. La directive n'est contraignante que pour les agences fédérales civiles du pouvoir exécutif ; la CISA encourage les autres organisations à adopter la même priorisation fondée sur les risques sans l'exiger.

On ne sait pas si quelqu’un en dehors d’un {{1}}pot de miel{{/1}} a agi avant l’échéance. Ni {{2}}CISA{{/2}} ni {{3}}BerriAI{{/3}} n’ont publié de chiffres sur le nombre de déploiements LiteLLM exposés, sur le nombre de ceux qui ont été corrigés avant le 16 septembre, ni sur le nombre de ceux qui ont été atteints par le contournement.

Ce qui reste ouvert

Trois lacunes méritent d’être signalées plutôt que dissimulées. Aucun rapport public d’incident ne relie CVE-2026-59822 à une intrusion spécifique ; l’inscription dans la liste KEV repose donc sur les preuves d’exploitation de la CISA et sur les observations de pots de miel de Wiz, plutôt que sur une victime documentée. Aucune déclaration du fournisseur n’explique comment le chemin de repli en est venu à être écrit ainsi, ni combien de temps il a existé avant la version 1.84.0 — l’avis décrit le défaut et son correctif, pas son historique. Et les échéances du lot n’étaient pas uniformes : cinq des sept entrées ajoutées le 2 septembre étaient assorties d’une échéance au 5 septembre, tandis que les entrées LiteLLM et Starlette étaient assorties d’une échéance au 16 septembre. La CISA ne précise pas pourquoi.

Ce qui est établi est plus restreint et plus utile que le score. Un seul caractère dans un en-tête Authorization était, sur les versions concernées, impossible à distinguer d’une clé valide pour le point de terminaison MCP — et les versions qui se comportaient ainsi ont cessé d’être actuelles en mai 2026.