LiteLLM, la passerelle open source qui centralise les clés d'API de la moitié de la planète IA, a publié ce 30 septembre un avis de sécurité « High ». Un simple utilisateur interne peut devenir administrateur, puis exécuter du code à distance sur la machine. La cause tient en une phrase : la même clé de chiffrement sert à sceller les secrets et à signer les sessions. C'est le troisième passage de LiteLLM au catalogue KEV de la CISA en quatre mois.
Une clé, deux serrures
L'avis, c'est le GHSA-7hp6-4w63-5g45, publié le 30 septembre 2026. Sévérité High. Score CVSS v4 de 7,7. Et un résumé qui va droit au but : un utilisateur authentifié avec les privilèges internal_user peut s'élever au rang de proxy_admin et obtenir l'exécution de code à distance.
Le mécanisme se joue en trois temps. Un simple utilisateur interne demande la création d'une clé d'API. Il glisse dans le champ metadata une charge utile : une fausse identité d'administrateur. Le proxy la chiffre avec sa clé unique, celle qui sert aussi à sceller les secrets au repos, et la lui renvoie. L'attaquant la représente alors comme jeton de session. Le proxy la déchiffre avec la même clé, croit l'identité contrefaite, et lui ouvre l'administration complète.
De là, il ne reste qu'un pas. L'endpoint MCP stdio du proxy exécute du code arbitraire. Un pas, et c'est la machine qui tombe.
Faut appeler un chat un chat. Réutiliser un secret pour deux usages distincts, sceller des données et signer une identité, c'est donner à quiconque peut faire chiffrer une donnée le pouvoir de forger une identité. Une erreur de conception cryptographique qu'on n'attend pas d'un composant qui se pose en gardien des clés d'API de milliers d'organisations.
La personne qui a trouvé la faille s'appelle Hoa X. Nguyen, de l'unité 515 d'OPSWAT. Le genre de découverte qu'on préfère lire chez les autres.
Le périmètre, précisément
Cinq branches de versions sont touchées. Les plages s'emboîtent, et c'est là que ça devient sérieux : la branche stable principale est exploitable en configuration par défaut.
Versions affectées | Correctif |
1.91.0 à 1.100.3 | 1.100.4 |
1.101.0 à 1.101.2 | 1.101.3 |
1.102.0 à 1.102.1 | 1.102.2 |
1.103.0 | 1.103.1 |
1.104.0rc1 | 1.104.0rc2 |
Les correctifs ont été poussés sur PyPI dans la nuit du 29 au 30 septembre, entre 23h04 et 00h16 UTC. Quelques heures avant l'avis. La version courante au 30 septembre est la 1.103.1.
Sur les versions 1.87.0 à 1.90.x, l'exploitation n'est possible que si on a activé EXPERIMENTAL_UI_LOGIN. En dessous de 1.91.0, la configuration par défaut ne suffit pas. C'est déjà ça.
Et pour ceux qui ne peuvent pas mettre à jour tout de suite ? L'avis propose de passer EXPERIMENTAL_UI_LOGIN à false. Sauf que ça a un prix : ça casse le SSO en ligne de commande et la connexion à la passerelle via Claude Code. Traduction : la mesure d'urgence ferme la porte, mais coupe un des usages les plus courants de LiteLLM, faire transiter les agents de codage par le point de contrôle de l'entreprise. Beaucoup d'équipes vont devoir choisir entre sécurité et usage quotidien.
2026, l'année noire
Cette faille n'arrive pas sur un terrain vierge. Loin de là. La base d'avis GitLab recense 38 CVE distinctes pour le paquet litellm : 12 en 2024, 2 en 2025, et 24 en 2026. Vingt-quatre. Rien que cette année.
Revenons en arrière, parce que l'historique raconte mieux que n'importe quel commentaire.
Mars 2026. Les versions 1.82.7 et 1.82.8, téléversées sur PyPI, contenaient une porte dérobée : un fichier litellm_init.pth malveillant qui exfiltrait identifiants et fichiers vers une API distante. L'attaque est passée par un détour, le composant de sécurité Trivy, lui-même compromis. Le rapport CloudSEK, repris par Kami Labs, chiffre le bilan à environ 2 500 organisations et 434 000 chaînes d'intégration potentiellement exposées. Les versions piégées sont restées en ligne environ 40 minutes. Le client Mercor a dit avoir subi une cyberattaque liée à ça.
Et le volet qui fâche le plus ici : la startup Delve certifiait automatiquement la sécurité du projet avec des agents IA. Elle avait délivré des sceaux SOC 2 et ISO 27001 à un dépôt dont le pipeline était compromis depuis des jours. La certification automatique vient de prendre un coup qu'elle va mettre du temps à encaisser.
Mai 2026. Le CERT Santé publie une alerte sur la CVE-2026-42208 : une injection SQL à 9,8 sur 10. La valeur de l'en-tête Authorization était concaténée directement dans une requête SQL, sans paramétrage, sur un chemin accessible sans authentification. Et dans les déploiements par défaut, l'utilisateur applicatif est superutilisateur PostgreSQL. Un attaquant distant non authentifié pouvait lire et modifier toutes les clés d'API stockées.
Juin 2026. Horizon3.ai documente une RCE non authentifiée : la CVE-2026-42271, injection de commande dans les endpoints de test du serveur MCP, chaînée à la CVE-2026-48710, contournement d'en-tête Host de Starlette. Exploitée dans la nature. The Hacker News parle d'un score CVSS combiné de 10,0.
Septembre 2026. La CISA ajoute un contournement d'authentification du module MCP à son catalogue KEV. ActuIA résume : troisième entrée LiteLLM au KEV en quatre mois.
Et maintenant, celle du 30 septembre. Le module MCP de LiteLLM est devenu le point d'entrée récurrent des compromissions.
Le fil Hacker News qui porte l'avis du 30 septembre est quasi muet au moment où j'écris : 1 point, 0 commentaire. La couverture n'a pas encore démarré. iamoi arrive donc tôt sur le sujet, mais soyons honnêtes : aucune exploitation dans la nature n'est confirmée pour cette faille précise, et aucun numéro CVE public ne lui est encore associé. C'est l'avis GitHub qui fait foi.
Pourquoi ça vous regarde
Il faut comprendre ce que fait LiteLLM. C'est une passerelle : un proxy unique entre les applications d'une entreprise et plus de 100 fournisseurs de modèles. OpenAI, Anthropic, Azure, Bedrock, Vertex, vLLM, Nvidia NIM. Il gère les clés virtuelles, les budgets, les quotas, la journalisation.
Autrement dit, LiteLLM concentre exactement ce qui a le plus de valeur : les clés d'API de tous les fournisseurs, les identifiants de facturation, les journaux de requêtes. Et de plus en plus les accès aux outils des agents. FailleWeb l'a dit mieux que moi : LiteLLM n'est plus un simple proxy applicatif, c'est un composant d'infrastructure critique.
Les chiffres confirment l'exposition. Le dépôt GitHub affiche 59 900 étoiles et 11 908 forks au 30 septembre. PyPI a servi 89,4 millions de téléchargements sur les 30 derniers jours, dont 3,37 millions rien que le 29 septembre. Le paquet cumule 3,38 milliards de téléchargements depuis sa création en juillet 2023.
Une RCE sur ce composant transforme un incident sur une interface IA en incident d'infrastructure. Accès aux clés fournisseurs, donc facturation et abus. Mouvement latéral vers l'infrastructure connectée. Modification des journaux. Déploiement de code dans les pipelines. Le tout, souvent, sur une VM ou un pod Kubernetes déployé « temporairement » et devenu critique, avec des clés de production en variables d'environnement. OPENAI_API_KEY, ANTHROPIC_API_KEY, AZURE_API_KEY. Derrière un simple reverse proxy, parfois.
Le vrai sujet n'est pas la faille
Le vrai sujet, c'est la récurrence. 38 CVE, 24 en un an, trois dépassements au KEV en quatre mois. La question n'est plus de savoir si une nouvelle faille arrivera, mais à quelle fréquence.
Il y a un second sujet, plus gênant encore. Pourquoi tout le monde a-t-il concentré ses secrets derrière un seul proxy ? LiteLLM incarne la promesse d'un point d'entrée unique pour plus de 100 fournisseurs. Mais un point unique, c'est aussi un point de défaillance unique.
La concurrence s'organise d'ailleurs sur ce terrain. Bifrost se présente comme « 90x faster than LiteLLM at p99 ». Aurora, un fork de passerelle, revendique « 55x faster than LiteLLM ». Portkey et OpenRouter proposent des alternatives hébergées. Et la migration de LiteLLM vers Rust, annoncée en juin 2026, n'a pas rassuré tout le monde : un fil Hacker News de novembre 2025, « Optimizing LiteLLM with Rust — when expectations meet reality », témoignait déjà du scepticisme.
Bref. Le problème n'est pas que LiteLLM est mauvais. C'est qu'il est devenu le standard de fait, et qu'un standard de fait avec 24 CVE par an, c'est un standard qui fait peur. Un projet sous double licence d'ailleurs : MIT hors du dossier enterprise/, licence spécifique pour l'édition entreprise. Pas intégralement open source, nuance à ne pas gommer.
Verdict
Faut pas déconner. Une faille de cette nature, avec une cause aussi bête, une clé recyclée pour deux usages, sur un composant qui garde les clés d'API de milliers d'organisations, ce n'est pas un incident isolé. C'est un signal.
LiteLLM est un excellent outil, massivement adopté, et c'est précisément le problème. Son statut de gardien unique en fait la cible parfaite. Et sa cadence de correctifs, cinq branches en une nuit, prouve que l'équipe réagit vite. Mais réagir vite à la vingt-quatrième CVE de l'année, c'est aussi reconnaître qu'on n'a pas réglé le fond.
Le fond, c'est l'architecture. Concentrer tous les secrets derrière un seul proxy devient intenable. Soit on désagrège, soit on traite enfin cette passerelle comme un composant de sécurité de premier rang, avec l'audit, la segmentation et la méfiance qui vont avec.
Si vous faites tourner LiteLLM, deux choses à faire aujourd'hui. Vérifier votre version : tout ce qui est sous 1.100.4, 1.101.3, 1.102.2 ou 1.103.1 est à mettre à jour. Et si vous ne pouvez pas, couper EXPERIMENTAL_UI_LOGIN, en sachant que vous perdez le SSO CLI et la passerelle Claude Code. Un mauvais compromis, mais moins mauvais qu'une RCE.
Cette fois, la note n'a pas besoin d'être sur 5. C'est binaire : mettez à jour, ou assumez.
Sources
- Avis GitHub GHSA-7hp6-4w63-5g45 — l'avis officiel : mécanisme, plages de versions, correctifs, CVSS 7,7, crédit OPSWAT Unit 515.
- Dépôt BerriAI/litellm — étoiles, forks, issues, licence.
- PyPI litellm — version courante 1.103.1, dates de téléversement des correctifs.
- Base d'avis GitLab litellm — les 38 CVE du paquet (12 en 2024, 2 en 2025, 24 en 2026).
- Kami Labs — compromission PyPI de mars 2026 : 2 500 organisations, 434 000 chaînes, Team PCP, 40 minutes d'exposition.
- CERT Santé — CVE-2026-42208, injection SQL, CVSS 9,8.
- Horizon3.ai — chaîne CVE-2026-42271 + CVE-2026-48710, RCE non authentifiée.
- The Hacker News — exploitation active, CVSS combiné 10,0.
- ActuIA — troisième entrée au KEV en quatre mois.
- FailleWeb — LiteLLM comme composant d'infrastructure critique.
- Fil Hacker News du 30 septembre — couverture communautaire quasi nulle au moment de la rédaction.
✦ Idée d'illustration
Un coffre-fort géant de banque, style néobrutaliste, couleurs vives et aplats contrastés. La porte blindée est grande ouverte, et à la place du mécanisme de serrure, on voit une unique clé en métal insérée dans deux serrures à la fois, façon impossible de M. C. Escher. Des câbles de clés API pendent de l'intérieur, étiquetés « OPENAI », « ANTHROPIC », « AZURE ». Au premier plan, un petit personnage en silhouette glisse une clé dans la fente et devient une silhouette d'administrateur avec un badge « proxy_admin ». Ambiance Canard Enchaîné : ironique, satirique, sans être macabre.
