La passerelle qui détient toutes vos clés d'IA est attaquée, alerte la CISA

La passerelle qui centralise toutes vos clés d'IA est désormais une cible

Les entreprises qui exploitent l'IA à grande échelle font généralement transiter leurs requêtes par un même composant, une passerelle d'IA. Ce serveur mandataire (proxy) s'intercale entre les applications maison et la dizaine de fournisseurs de grands modèles de langage sollicités au quotidien : il regroupe les clés d'API, suit les dépenses et répartit le trafic, ce qui évite aux équipes de câbler chaque fournisseur séparément. La version open source la plus répandue de cet outil se nomme LiteLLM. Le lundi 8 juin 2026, l'agence américaine de cybersécurité a confirmé que des attaquants exploitent activement une faille qui l'affecte.

Toute la gravité tient à l'emplacement de cette passerelle. C'est la seule machine qui réunit les clés de l'ensemble des modèles payés par l'organisation. La compromettre ne livre donc pas un secret, mais la totalité d'entre eux.

Les faits

La CISA (Cybersecurity and Infrastructure Security Agency, l'agence fédérale américaine qui recense les vulnérabilités déjà exploitées) a inscrit la faille, référencée CVE-2026-42271, à son catalogue des vulnérabilités activement exploitées, une liste réservée aux défauts dont l'usage en attaque est avéré. Sa note de gravité atteint 8,7 sur 10. BerriAI, l'éditeur de LiteLLM, l'avait révélée dès le mois d'avril. Elle touche toutes les versions du paquet LiteLLM comprises entre la 1.74.2 et la 1.83.7, cette dernière apportant le correctif.

Le procédé relève de l'injection de commande, une faille qui autorise un attaquant à faire exécuter ses propres commandes système sur la machine visée. LiteLLM proposait deux points d'accès destinés à tester un serveur MCP (Model Context Protocol, le connecteur standard qui permet à un assistant IA d'atteindre des outils externes) avant de l'enregistrer. Ces points d'accès de test acceptaient une configuration complète, y compris la commande à lancer. Lorsque cette configuration recourait au mode local « stdio », la passerelle exécutait docilement la commande fournie comme un processus sur son propre hôte, avec ses propres privilèges. Seule une clé d'API valide servait de barrière, sans aucune vérification des droits associés. Autrement dit, n'importe quel utilisateur authentifié, même titulaire de la clé la moins privilégiée, pouvait soumettre une commande et la voir s'exécuter.

• Les chercheurs de Horizon3.ai ont combiné cette faille avec une seconde, un contournement d'en-tête « Host » dans Starlette (le cadre web Python léger sur lequel LiteLLM s'appuie pour traiter les requêtes), surnommé BadHost, afin de supprimer toute exigence d'authentification. Réunies, les deux vulnérabilités donnent une exécution de code à distance sans le moindre identifiant, soit une gravité maximale de 10,0.
• Une attaque réussie permet de dérober les identifiants des fournisseurs de modèles et toutes les clés d'API stockées par le proxy, puis de rebondir vers l'infrastructure d'IA et les systèmes connectés en aval.
• La CISA impose aux agences fédérales civiles d'appliquer le correctif avant le 22 juin 2026. Aucune information publique ne précise encore l'identité des attaquants ni le nombre de systèmes touchés.

Pourquoi vos tuyaux d'IA deviennent la cible

Le préjudice ne se limite pas à la fuite d'une conversation de chatbot : c'est le coffre à identifiants situé au cœur de la pile d'IA d'une entreprise qui est en jeu. Pour épargner à chaque équipe la gestion séparée des accès fournisseurs, la passerelle les rassemble : clé OpenAI, clé Anthropic, identifiants cloud, accès à la facturation, le tout dans un seul service. Cette commodité fait précisément sa valeur pour un attaquant, car une unique exécution de code sur le proxy livre l'ensemble d'un coup, avec à la clé un accès aux outils internes que la passerelle était autorisée à atteindre. Si vos équipes techniques ont déployé LiteLLM pour discipliner la prolifération de l'IA, la question dérangeante consiste à se demander si cette machine n'est pas devenue la moins défendue alors même qu'elle abrite vos clés les plus sensibles. Reste la tendance de fond, celle qu'il faut emporter en réunion de cadrage. Il s'agit de la deuxième faille de LiteLLM transformée en arme en l'espace d'un mois, après une injection de base de données que les attaquants avaient su exploiter en trente-six heures au mois d'avril, et elle succède à une attaque de la chaîne d'approvisionnement qui avait glissé des paquets LiteLLM malveillants sur l'index Python (PyPI) en mars. La tuyauterie d'IA que les organisations ont greffée dans l'urgence depuis deux ans constitue désormais une surface d'attaque à part entière, et les attaquants ont remarqué qu'elle est souvent déployée plus vite qu'elle n'est sécurisée.

À mettre en place sans attendre

1. Passez LiteLLM en version 1.83.7 ou ultérieure et Starlette en 1.0.1 ou ultérieure. La passerelle corrigée réserve l'accès aux points de test au rôle d'administrateur et referme le contournement d'en-tête, ce qui brise à la fois l'attaque directe et la chaîne sans identifiant.
2. Faute de pouvoir corriger aujourd'hui, bloquez les points de test et renouvelez les clés. Coupez l'accès aux deux points de test MCP au niveau de votre proxy inverse, cantonnez la passerelle à des segments réseau de confiance et renouvelez chaque identifiant qu'elle conserve, car une faille activement exploitée oblige à considérer ces secrets comme potentiellement déjà exposés.
3. Cessez de traiter la passerelle d'IA comme une brique d'infrastructure ordinaire. Attribuez-lui son propre segment réseau et sa propre surveillance, et scrutez ses journaux à la recherche de processus inattendus ou d'en-têtes « Host » anormaux, car une machine qui détient toutes les clés des modèles mérite la même vigilance qu'un coffre-fort de mots de passe.

À retenir

CVE-2026-42271 n'a rien d'exotique. C'est une banale injection de commande dans un outil de confort, le genre de défaut qui passerait presque inaperçu sur un serveur web classique. Sa gravité tient au rôle que joue ce serveur. Une passerelle d'IA existe pour réunir en un seul endroit tous les identifiants de modèles, ce qui explique précisément qu'une faille unique y atteigne la note maximale. La leçon pour votre prochaine revue d'architecture tient en peu de mots : le logiciel déployé pour gérer l'IA est devenu une infrastructure convoitée, alors protégez-le comme le coffre qu'il est discrètement devenu, et vérifiez dès aujourd'hui si la version en service fait partie de celles sur lesquelles un inconnu peut déjà exécuter du code. Les détails de référence figurent dans l'avis de la CISA et dans l'avis de sécurité publié par BerriAI.