LiteLLM, la passerelle qui garde les clés de votre IA, est sous attaque

Une simple clé API suffisait pour exécuter des commandes sur le serveur qui aiguille l'IA de votre entreprise

LiteLLM fait partie de la tuyauterie discrète sur laquelle repose une bonne part de l'IA en entreprise. Cette passerelle open source s'intercale entre les applications d'une société et les différents modèles d'IA qu'elles sollicitent, et elle conserve les clés d'accès de chacun d'eux. Le 8 juin 2026, l'agence américaine de cybersécurité, la CISA, a inscrit une faille de LiteLLM à son catalogue des vulnérabilités activement exploitées, une liste réservée aux bogues dont les attaquants se servent déjà. Les agences fédérales ont jusqu'au 22 juin pour appliquer le correctif.

Référencée CVE-2026-42271, la vulnérabilité affiche un score de gravité de 8,7 sur 10. Prise isolément, elle permet à n'importe quel utilisateur connecté de lancer des commandes sur la machine qui héberge LiteLLM. Combinée à une seconde faille, elle offre la même latitude à un inconnu dépourvu du moindre compte. Pour un système dont la seule fonction consiste à garder les clés de votre IA, on touche au pire scénario envisageable.

Comment l'attaque opère

Tout part d'une fonction de confort. LiteLLM autorise un administrateur à prévisualiser la connexion à un serveur MCP (le connecteur qui permet à un assistant d'IA d'atteindre un outil ou une source de données externe) avant de l'enregistrer. Deux points d'entrée géraient cette prévisualisation, et ils acceptaient dans le corps de la requête une configuration de serveur complète, commande à exécuter et paramètres compris. Dès lors qu'on leur transmettait une configuration de type « stdio », LiteLLM s'exécutait au sens propre : il lançait la commande fournie sous forme de processus sur son propre hôte, avec ses propres privilèges. Le problème tient à ce que ces points d'entrée n'étaient protégés que par une clé API valide. Tout utilisateur authentifié, fût-il porteur d'une clé interne à faibles droits, pouvait donc confier une commande à LiteLLM et la lui faire exécuter. Voilà ce qu'on nomme une injection de commande, le genre de défaut qui transforme un bouton de test anodin en accès distant.

Les chercheurs de Horizon3.ai ont ensuite fait sauter le dernier verrou. Ils ont chaîné la CVE-2026-42271 avec la CVE-2026-48710, une faille distincte de Starlette (le cadriciel web sur lequel reposent de nombreux services Python, LiteLLM compris) qui permet de déjouer une vérification d'en-tête Host servant à l'authentification. Réunies, les deux failles atteignent le score maximal de 10,0 et ne réclament aucun identifiant. Les mainteneurs ont colmaté la brèche de LiteLLM dans la version 1.83.7 en imposant un rôle d'administrateur sur les points d'entrée concernés ; Starlette, de son côté, a été corrigé en version 1.0.1.

• Les versions vulnérables vont de la 1.74.2 jusqu'à la 1.83.7 exclue. Toute installation antérieure au correctif reste exposée.
• Une intrusion réussie donne accès aux identifiants des fournisseurs de modèles et aux clés API conservées par le proxy, autorise l'exécution de commandes arbitraires et ouvre la voie à un déplacement latéral vers l'infrastructure d'IA connectée.
• C'est la deuxième faille de LiteLLM activement exploitée en deux mois. En avril, une injection SQL avait été attaquée dans les 36 heures suivant sa publication.

Pourquoi le dossier atterrit sur le bureau du RSSI, pas sur celui des équipes data

La CISA n'inscrit pas une faille à sa liste des vulnérabilités exploitées sur de simples soupçons : la mention d'attaques en cours constitue donc le préjudice déjà avéré, et la version chaînée tend à un inconnu sans identifiant le pouvoir d'exécuter du code et de repartir avec les secrets. Ce qui rend l'affaire douloureuse, c'est la position qu'occupe LiteLLM. Une passerelle de ce type attire précisément parce qu'elle est centrale : elle réunit les clés de tous les modèles que votre organisation paie, elle est souvent exposée sur Internet pour rester joignable par des applications réparties, et elle est fréquemment déployée par une équipe d'apprentissage automatique pressée plutôt que par le service de sécurité qui durcirait un service classique ouvert sur le web. Si votre entreprise exploite un proxy de ce genre, vous tenez là l'une de vos cibles les plus précieuses, et sans doute l'une des moins surveillées. La tendance de fond mérite d'être posée sur la table lors de votre prochaine revue : les intergiciels d'IA sont devenus un terrain de chasse, et le délai entre la divulgation d'une faille et son exploitation se compte désormais en heures, et non plus en semaines. LiteLLM en aura fourni deux exemples en deux mois.

À mettre en place sans attendre

1. Passez LiteLLM en version 1.83.7 ou supérieure, et Starlette en 1.0.1 ou supérieure. C'est la seule mesure qui referme la brèche au lieu de la rétrécir, car le correctif rétablit le contrôle réservé aux administrateurs que ces points d'entrée auraient toujours dû exiger.
2. Si la mise à jour ne peut pas attendre, bloquez les deux points d'entrée de prévisualisation et retirez la passerelle d'Internet. En filtrant POST /mcp-rest/test/connection et POST /mcp-rest/test/tools/list au niveau de votre reverse proxy, vous coupez la portée de l'attaquant le temps de planifier la montée de version.
3. Partez du principe que les clés ont déjà fuité, et renouvelez-les. Faites tourner chaque identifiant de fournisseur de modèle et chaque secret stocké par le proxy, puis passez ses journaux au crible pour repérer des en-têtes Host inhabituels et des processus imprévus, car une clé dérobée survit au correctif qui a refermé la porte derrière elle.

À retenir

LiteLLM n'a fait que ce pour quoi il a été conçu : exécuter une commande que lui confiait un utilisateur authentifié. L'ennui, c'est qu'il n'exigeait presque rien avant de s'exécuter, et qu'il veille sur les clés de toute la pile d'IA d'une organisation. Traitez votre passerelle d'IA comme n'importe quel autre système qui détient des identifiants de production et fait face à Internet : appliquez les correctifs sans délai, surveillez-la de près, et partez du principe que quelqu'un la sonde déjà. L'entrée se suit dans le catalogue des vulnérabilités activement exploitées de la CISA, et le détail technique figure dans l'avis de sécurité publié par les mainteneurs de LiteLLM. Si le proxy qui aiguille votre IA était compromis ce soir, combien de temps s'écoulerait-il avant que quelqu'un s'en aperçoive, et combien de clés devriez-vous renouveler ?