Le 2 septembre, l'agence américaine de cybersécurité CISA a ajouté sept vulnérabilités à son catalogue des failles activement exploitées, le KEV (Known Exploited Vulnerabilities). Parmi elles, CVE-2026-59822, un contournement d'authentification dans LiteLLM, passerelle open source (licence MIT, hors répertoire entreprise) qui route les appels des applications vers OpenAI, Anthropic, Azure, Gemini et une centaine d'autres API au format OpenAI. Les agences fédérales ont jusqu'au 16 septembre pour corriger. L'information n'a circulé que dans les flux spécialisés. Elle touche pourtant une couche que beaucoup d'entreprises ont installée en 2025 sans la traiter comme un actif critique, le proxy qui s'interpose entre leurs applications et les fournisseurs de modèles.
Un en-tête Authorization fabriqué suffisait
Le mécanisme est décrit par la fiche NVD et par l'avis de sécurité publié sur le dépôt GitHub de BerriAI le 30 juin. LiteLLM sert de passerelle MCP (Model Context Protocol), un point d'entrée unique vers les serveurs d'outils que les agents peuvent appeler, avec des droits attribués par clé, par équipe ou par organisation. Pour les serveurs MCP protégés par OAuth2, le gestionnaire d'authentification acceptait de relayer le jeton de l'appelant. Le défaut se logeait dans le repli. Quand la validation de la clé LiteLLM échouait, le code interprétait cet échec comme un cas de relais OAuth2 et renvoyait un objet UserAPIKeyAuth vide, sans aucune restriction. Un en-tête Authorization fabriqué, avec n'importe quel jeton, ouvrait une session MCP authentifiée.
La demande de fusion qui corrige le problème, ouverte le 25 avril et fusionnée le 30, décrit deux chemins de contournement dans le même gestionnaire, ce repli OAuth2 qui échoue en position ouverte et une détection des routes publiques qui cherchait la chaîne « .well-known » dans l'URL complète, paramètres compris. Combinés à des serveurs MCP configurés pour accepter toutes les clés, ils donnaient à un appelant non authentifié la liste des outils et la possibilité de les appeler. Le correctif figure dans la version 1.84.0, publiée le 14 mai. GitHub note la faille 8,8 en CVSS 4.0 ; le NIST, 8,2 en CVSS 3.1. La fiche CVE, elle, n'est publiée que le 8 juillet, près de huit semaines après la sortie de la version corrigée.
L'exploitation est documentée par Wiz, dont l'équipe de recherche revendique la découverte de la faille. Dans un billet du 27 août, l'éditeur décrit 90 jours de télémétrie sur des honeypots imitant LiteLLM, Langflow, Flowise ou Ollama, et dit avoir observé des requêtes munies d'un jeton d'un seul caractère visant les points d'énumération des modèles. C'est le type de preuve que la CISA exige avant inscription. Ses critères retiennent l'exploitation tentée, y compris contre un honeypot, et excluent le simple balayage comme la preuve de concept.
Trois entrées en quatre mois, deux sur le module MCP
Le flux JSON du catalogue, daté du 4 septembre, contient trois entrées BerriAI LiteLLM. Le 8 mai, une injection SQL dans la vérification des clés d'API (CVE-2026-42208, notée 9,8 en CVSS 3.1, signalée par Tencent YunDing Security Lab) : un en-tête Authorization forgé, envoyé à n'importe quelle route d'API, atteignait la base de données du proxy et les identifiants qu'elle gère. Le 8 juin, une injection de commande (CVE-2026-42271). Deux points de terminaison servant à tester un serveur MCP avant de l'enregistrer acceptaient une configuration stdio complète, commande comprise, et l'exécutaient sur l'hôte avec les droits du proxy, pour tout détenteur d'une clé, même peu privilégiée. Ces deux failles sont corrigées en 1.83.7 ; la troisième en 1.84.0.
Wiz rapporte avoir vu la deuxième servir à déposer un mineur de cryptomonnaie, la sortie des commandes étant renvoyée dans le champ description d'un faux outil MCP. Le 2 septembre, la CISA a d'ailleurs inscrit le même jour une faille du framework web Starlette (CVE-2026-48710), en précisant dans la fiche qu'elle « pourrait être chaînée » avec cette injection de commande de juin.
La série dépasse LiteLLM. Depuis fin mars 2026, le catalogue a accueilli dix entrées visant des outils d'infrastructure IA publiés en open source : cinq pour Langflow (dont sa déclinaison IBM), trois pour LiteLLM, une pour Ray le 17 août, une pour MLflow le 19 août. Langflow avait été le premier de la liste le 5 mai 2025, avec une faille d'authentification manquante qu'ActuIA avait signalée. MLflow, dont ActuIA rapportait une faille critique dès avril 2023, y figure désormais aussi.
Une passerelle conçue pour concentrer clés, budgets et outils
Pourquoi une passerelle intéresse-t-elle autant les attaquants ? Parce qu'elle a été conçue pour concentrer. Un proxy LiteLLM détient les clés de chaque fournisseur vers lequel il route, applique les budgets et les quotas par équipe, journalise les requêtes et, depuis l'arrivée de la passerelle MCP, sert de porte vers les outils internes que les agents peuvent appeler, bases de données, dépôts de code, messageries, API métier. Wiz parle de « concentration d'identifiants » : compromettre le proxy donne accès à ce qui se trouve en aval, pas seulement au proxy.
Le billet du 27 août décrit aussi la suite d'une intrusion réussie. Plutôt que de fouiller le disque, les attaquants interrogeaient l'état des modules Python du processus pour extraire la clé maîtresse en mémoire, énuméraient les fichiers de configuration propres à LiteLLM, puis testaient quels fournisseurs répondaient derrière le proxy, afin de choisir entre le vol de clé et l'usage frauduleux du quota d'inférence. Sur les instances laissées avec la clé maîtresse par défaut de la documentation, l'énumération des modèles suivait immédiatement.
Cette architecture n'est pas une erreur de conception, c'est la promesse même du produit, un point unique de contrôle et de dépense. Le revers est mécanique. La couche d'intermédiation hérite du niveau de criticité de tout ce qu'elle relie, et beaucoup d'organisations l'ont déployée comme un composant de commodité, à côté d'un tableau de bord, avec une clé partagée et une exposition réseau pensée pour les développeurs. Trois inscriptions au KEV en quatre mois signalent la fin de cette période. Un proxy LLM relève désormais du traitement réservé à une passerelle d'API ou à un gestionnaire de secrets, avec un inventaire, un propriétaire, des mises à jour sous délai et une exposition réduite au strict nécessaire.