Les agences fédérales américaines ont jusqu’au 16 septembre pour corriger une brique que beaucoup d’entreprises font tourner sans l’avoir inventoriée. Le 2 septembre, la CISA, l’agence américaine de cybersécurité, a inscrit la faille CVE-2026-59822 à son catalogue KEV (Known Exploited Vulnerabilities), celui des vulnérabilités dont l’exploitation est constatée sur le terrain : un contournement d’authentification dans LiteLLM. Troisième entrée en quatre mois pour la même passerelle.
LiteLLM route les appels des applications vers OpenAI, Anthropic, Azure, Gemini et une centaine d’autres API au format OpenAI. Open source, sous licence MIT, absente de la plupart des inventaires logiciels, elle s’est installée en 2025 dans nombre d’architectures IA pour une raison très prosaïque : elle évite de réécrire le code à chaque changement de fournisseur. Au passage, elle concentre les clés d’API, les prompts, les quotas et, depuis l’arrivée des agents, la liste des outils MCP (Model Context Protocol, le standard qui expose des outils aux modèles) que ces agents ont le droit d’appeler.
Un jeton d’un seul caractère ouvrait la session
Le mécanisme est décrit par la fiche du NVD, la base de vulnérabilités du NIST, et par l’avis de sécurité publié le 30 juin sur le dépôt GitHub de BerriAI. LiteLLM sait relayer le jeton OAuth2 d’un appelant vers les serveurs MCP qui l’exigent. Quand la validation de la clé LiteLLM échouait, le code prenait cet échec pour un cas de relais OAuth2 et renvoyait un objet d’authentification vide, sans la moindre restriction. Un en-tête Authorization fabriqué, avec n’importe quel jeton, et la session MCP s’ouvrait.
La pull request qui corrige le défaut, ouverte le 25 avril et fusionnée le 30, documente deux chemins dans le même gestionnaire : ce repli qui échoue en position ouverte, c’est-à-dire qui laisse passer au lieu de bloquer, et une détection des routes publiques qui cherchait la chaîne .well-known dans l’URL complète, paramètres compris. Sur des serveurs MCP configurés pour accepter toutes les clés, un appelant anonyme récupérait la liste des outils et pouvait les déclencher.
Wiz, dont l’équipe de recherche revendique la découverte, a publié le 27 août 90 jours de télémétrie recueillie sur des honeypots, ces machines-appâts exposées pour attirer les attaques. Les leurres imitaient LiteLLM, Langflow, Flowise et Ollama. Des requêtes munies d’un jeton d’un seul caractère y ont visé les routes qui listent les modèles disponibles. La CISA exige ce type de preuve : elle retient l’exploitation tentée, y compris contre un leurre, et écarte les simples balayages ainsi que les preuves de concept.
Langflow, présente dans le même dispositif de leurres, avait ouvert la voie : une exécution de code à distance notée 9,8 l’a fait entrer au catalogue de la CISA dès mai 2025, où elle a servi à déployer un botnet, un réseau de machines infectées pilotées à distance. L’outillage qui entoure les modèles attire aujourd’hui les mêmes campagnes que les modèles eux-mêmes.
Huit semaines entre le correctif et la fiche CVE
Le correctif est sorti dans la version 1.84.0, publiée le 14 mai. La fiche CVE, l’entrée qui décrit publiquement la vulnérabilité, n’est arrivée que le 8 juillet, près de huit semaines plus tard. Inscription au KEV le 2 septembre. GitHub note la faille 8,8 sur l’échelle de gravité CVSS 4.0, le NIST 8,2 sur la version 3.1 de cette échelle.
Une équipe qui surveille consciencieusement les alertes CVE de son parc n’a donc découvert le problème que le 8 juillet, plus de deux mois après la fusion du correctif. Celles qui suivent les mises à jour du dépôt l’ont su fin avril. L’écart entre ces deux dates mesure assez bien le statut réel accordé à la couche d’accès aux modèles : une dépendance parmi d’autres, mise à jour quand le temps le permet.
Deux entrées sur trois visent le module MCP
Le flux JSON du catalogue, daté du 4 septembre, contient trois entrées BerriAI LiteLLM. La CISA y a inscrit 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 le Tencent YunDing Security Lab : un en-tête Authorization forgé, envoyé à n’importe quelle route, atteignait la base de données du proxy et les identifiants qu’elle gère. Puis, 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 de lancement local complète, commande système comprise. Et maintenant le contournement d’authentification.
Deux de ces trois failles touchent la partie MCP, la plus jeune du produit. Rien de surprenant sur du code écrit vite pour suivre un standard qui bouge. Leur ordre d’apparition en dit plus : la première visait les identifiants stockés, les deux suivantes visent les outils que les agents déclenchent. On est passé du vol de clés au pilotage des actions.
Trois conditions pour que la passerelle change de statut
Rien ne garantit le basculement, mais trois conditions le décideraient. Une quatrième inscription au KEV sur cette famille d’outils, que le rythme actuel rend probable. Un incident public chez une entreprise identifiable, avec des prompts ou des clés exfiltrés. Et surtout un questionnaire d’audit ou d’assurance qui demande la version du proxy au même titre que celle de l’hyperviseur. Les deux premières relèvent du calendrier ; la troisième seule change les budgets. Réunies, elles feraient basculer la passerelle LLM de la plomberie vers les équipements de bordure d’ici le printemps 2027 : propriétaire nommé, version suivie, journaux relus.
Le scénario inverse tient debout lui aussi. Les fournisseurs managés absorbent la fonction de routage, l’entreprise cesse d’héberger sa propre passerelle, et le problème se déplace chez un tiers qui, lui, corrige en quelques heures. Le confort a un prix connu : la télémétrie des prompts change de propriétaire.
En attendant, deux vérifications suffisent. Comparer la version installée à 1.84.0, et regarder si les serveurs MCP déclarés acceptent réellement toutes les clés, condition sans laquelle le contournement reste sans effet. Aucune échéance réglementaire ne pèse sur les entreprises françaises, contrairement aux agences fédérales américaines. Reste un numéro de version à vérifier, et un prochain avis qui mettra sans doute autant de temps à parvenir aux équipes.
Sources
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 16 évaluations
Faire appel à mes services →
