Wiz : près d'une passerelle LiteLLM exposée sur dix accepte la clé d'administration d'exemple sk-1234

Le 9 septembre 2026, Wiz Research a publié une étude sur LiteLLM, la passerelle d’IA open source qui se trouve entre les applications et les fournisseurs de modèles qu’elles paient, et a rapporté que 294 des 3 074 déploiements de LiteLLM qu’elle pouvait atteindre sur l’internet public — 9,6 %, près d’un sur dix — acceptaient sk-1234, la clé maître d’exemple imprimée dans la documentation de configuration du projet, ou n’exigeaient aucun identifiant. Cette chaîne n’est pas une clé API ordinaire : dans LiteLLM, elle est à la fois l’identifiant administrateur et l’interrupteur qui active l’authentification, de sorte que quiconque la présente peut lire toutes les clés de fournisseur de modèles stockées sur la passerelle, observer chaque prompt et chaque complétion qui la traversent, et atteindre chaque serveur d’outils connecté via le Model Context Protocol. Les coauteurs de Wiz, Amitai Cohen et Yaara Shriki, ont enchaîné cet accès à une exécution de code au niveau root et au vol des identifiants IAM cloud de l’hôte. Ce compte rendu s’appuie sur le rapport de Wiz, les propres avis de sécurité de LiteLLM et la liste Known Exploited Vulnerabilities de la CISA qui a suivi, et l’archive des incidents d’IA contient cet enregistrement aux côtés de ses voisins, chacun avec ses propres sources, son niveau de gravité et son degré de confiance.

La date de publication est la seule date que porte l’enregistrement, et c’est une date de publication. Le scan à l’origine du gros titre a été réalisé en février 2026 ; les deux failles de code décrites par Wiz avaient reçu des correctifs au plus tard à la mi-mai, dans des versions que les propres archives du projet datent de mars et de mai ; les identifiants CVE ont été attribués en juillet ; et l’inscription au catalogue est arrivée en septembre. Presque tout ce que contient le rapport était déjà ancien au moment où il a été imprimé, ce qui constitue une large part de l’argumentation du rapport.

Les 9,6 % correspondent à un seul scan, et Wiz indique que son propre suivi d’août ne peut pas y être comparé.

La mesure est simple et Wiz expose clairement sa méthode : 3 074 proxys LiteLLM exposés à Internet trouvés via Shodan en février 2026, chacun testé pour déterminer s’il s’authentifierait avec la clé d’exemple documentée. Sur ce total, 294 l’ont fait. Au sein de ce groupe, 191 n’avaient aucune clé maître configurée et auraient accepté n’importe quelle chaîne qui leur était proposée ; les autres avaient laissé en place l’espace réservé du guide d’installation. Aucun de ces deux modes de défaillance ne nécessite un bogue logiciel. Les deux n’ont besoin que de l’adresse de la passerelle et de la valeur imprimée dans le README du projet lui-même.

Il s'agit également du scan d'un seul fournisseur. Le chiffre de Wiz a été repris par l'AI Safety Initiative de la Cloud Security Alliance le 10 septembre et par The Hacker News le même jour, mais les deux le reprennent en l'attribuant, et aucune réplication indépendante du chiffre de 3 074 n'a été trouvée pour cet article. Wiz a réalisé un deuxième scan en août 2026 et a trouvé plus de 85 000 instances, soit environ vingt-sept fois le décompte de février. L'entreprise indique que la plupart d'entre elles semblent être des honeypots ou des déploiements de test, et que les deux décomptes ne peuvent pas être comparés. Il n'existe aucun chiffre d'exposition actuel, et tout article qui en cite un cite celui de février.

Un autre chiffre du rapport provient de la télémétrie de Wiz elle-même plutôt que d’un scan : l’entreprise indique que LiteLLM est présent dans environ un tiers des environnements cloud qu’elle observe. Il s’agit du point de vue d’un fournisseur sur sa propre base de clients, qu’il convient de prendre avec des pincettes, mais cela explique pourquoi les chercheurs ont considéré une mauvaise configuration de passerelle comme un problème de cloud plutôt que comme un problème d’application.

La clé principale est à la fois l'identifiant d'administration et l'interrupteur qui active l'authentification.

La conception de LiteLLM confie deux rôles à un même secret. La master key authentifie les requêtes administratives, et sa présence est ce qui active l’authentification tout court : sans master key ni configuration JWT ou OAuth2, le proxy fonctionne ouvert et accepte toutes les requêtes. Wiz s’est penché sur la base de code avec Claude Code d’Anthropic, à la recherche de fonctionnalités qui prennent des entrées contrôlées par l’utilisateur et les transmettent à un contexte d’exécution ; le gestionnaire d’authentification figurait parmi les trois surfaces signalées.

Avant la version v1.82.0-stable, la conséquence de cette seconde tâche était pire qu’un proxy ouvert. Wiz a découvert que, lorsqu’aucune clé maîtresse n’était définie, le gestionnaire d’authentification attribuait le rôle PROXY_ADMIN à chaque requête entrante, si bien qu’un appelant non authentifié n’était pas simplement admis, mais admis en tant qu’administrateur. La pull request #22095, citée dans le rapport, a remplacé le rôle par défaut par INTERNAL_USER et ajouté une vérification d’administrateur aux points de terminaison des garde-fous.

L’accès administratif à une passerelle n’est pas un privilège étroit. L’instance détient une clé API pour chaque fournisseur vers lequel elle achemine les requêtes, ce qui en fait une cible pour le LLMjacking — l’exécution de charges de travail de modèles aux frais de la victime. Elle voit les prompts et les complétions. Elle se connecte vers l’extérieur à des serveurs d’outils MCP, qui, dans un déploiement interne, sont susceptibles d’inclure des gestionnaires de tickets, des outils de chat, des bases de données et des pipelines de déploiement.

Wiz a également démontré un chemin depuis ce poste d'administration jusqu'à l'identité cloud de l'hôte. LiteLLM permet à un administrateur d'enregistrer une route de relais vers n'importe quelle URL cible, et la cible n'est pas vérifiée par rapport aux plages d'adresses privées, à localhost ou à l'adresse des métadonnées cloud. Pointer une route vers le service de métadonnées de l'instance renvoie les identifiants IAM sous lesquels s'exécute la charge de travail. Le passage du service de métadonnées à IMDSv2, qui contrecarre normalement cette classe de falsification de requête en exigeant un jeton de session obtenu séparément, n'aide pas : LiteLLM transmet tout en-tête préfixé x-pass- à la cible en retirant le préfixe, ce qui permet de faire passer l'en-tête de jeton en contrebande. Wiz affirme que la fonctionnalité fonctionne sans doute comme prévu dans un modèle de menace qui fait confiance aux administrateurs, et qu'elle n'est donc associée à aucune CVE ni à aucun correctif.

Ce dernier paragraphe est une démonstration, pas une attaque observée. Hacker News, qui rapporte la recherche le 10 septembre, indique qu’aucune source ne rapporte que quiconque l’a fait contre un déploiement réel, et que cela nécessite d’abord un accès administrateur. Le cadrage de Wiz est le même : le pass-through est une propriété de conception qui ne devient une vulnérabilité que lorsque l’identifiant administrateur est une chaîne issue de la documentation.

8,8 et 2,1 évaluent la même chaîne à partir de positions de départ différentes

Deux CVE portent les constats techniques, et leurs scores publiés ne pourraient guère être plus éloignés.

La CVE-2026-59822 correspond au contournement d'authentification de MCP, et l'avis de LiteLLM le classe comme élevé, 8,8 selon le CVSS 4.0, sans privilèges requis, sans interaction utilisateur et sans exigences d'attaque. Le point de terminaison MCP dispose de son propre gestionnaire d'authentification, conçu pour accepter soit une clé LiteLLM, soit un jeton OAuth2 destiné à un serveur d'outils en amont. Lorsqu'un jeton échouait à la validation de LiteLLM, le gestionnaire interceptait le 401 et substituait un objet d'authentification vide au lieu de rejeter la requête. N'importe quel jeton Bearer produisait donc une session MCP valide, y compris un seul caractère : la preuve de concept de Wiz envoie un jeton bearer d'une lettre et reçoit en retour un identifiant de session. La faille est corrigée dans la version 1.84.0.

CVE-2026-59821 est la faille de garde-fou, et l'avis du même projet lui attribue la note Low, 2.1, avec des privilèges élevés requis et des exigences d'attaque présentes. La fonctionnalité de garde-fou par code personnalisé permet à un administrateur de soumettre du Python que le serveur compile et exécute. Le point de terminaison de test de l'interface Web validait le code par rapport à une liste de motifs interdits et retirait les builtins avant de l'exécuter ; les points de terminaison de création et de mise à jour en production ne faisaient ni l'un ni l'autre. Python repeuple les builtins lorsqu'ils sont absents, de sorte que le code soumis atteignait la bibliothèque standard. La preuve de concept de Wiz enregistre un garde-fou qui exécute une commande shell au moment de l'enregistrement — avant toute requête de modèle — et renvoie la sortie de la commande comme motif de blocage, laquelle, dans son test, était root. La faille est corrigée dans v1.82.0-stable.

Les deux descriptions sont compatibles, et la phrase qui les concilie se trouve dans l’avis lui-même : LiteLLM note que, dans les déploiements sans clé principale configurée, les appelants pouvaient être traités comme des administrateurs du proxy, ce qui a placé les points de terminaison de garde-fou à portée. A 2.1 suppose un utilisateur privilégié. La chaîne de Wiz est ce qui se produit lorsque la clé par défaut rend chaque appelant privilégié. Aucun des deux scores ne se trompe sur sa propre position de départ ; ils ne sont pas d’accord sur la fréquence à laquelle cette position est libre.

Une réserve s’attache à l’affirmation de Wiz selon laquelle, après 1.82.0, un attaquant disposant de la clé par défaut ne pouvait exécuter du code qu’à l’intérieur d’un bac à sable. The Hacker News renvoie à un avis distinct de mai 2026, CVE-2026-40217, qui décrit une évasion de ce bac à sable au moyen de techniques de bytecode dans les versions allant de 1.81.8 jusqu’à 1.83.10 non incluse, au sein d’un processus proxy dont l’avis indique qu’il s’exécute en tant que root dans l’image de conteneur par défaut. Atteindre ce point de terminaison nécessite un identifiant d’administrateur de proxy, ce qui est précisément ce qu’est la clé maîtresse.

Le 8.8 n’est pas non plus universel. La note de recherche de la Cloud Security Alliance observe que l’avis de GitLab indique un score de base de 8.2 pour la même faille et refuse de trancher entre les deux méthodologies, en notant seulement que les deux se situent dans la plage élevée. La gravité élevée indiquée dans l’enregistrement ne dépend pas du nombre utilisé.

Une CVE a été exploitée dans la nature ; l’exposition de la clé par défaut ne compte aucune victime nommée

CISA a ajouté la CVE-2026-59822 au catalogue Known Exploited Vulnerabilities le 2 septembre 2026 et fixé au 16 septembre 2026 la date limite de remédiation pour les agences fédérales civiles ; l'entrée du catalogue porte les CWE-287 et CWE-306, authentification incorrecte et absence d'authentification. La note de la Cloud Security Alliance indique que des observateurs du secteur l'ont décrite comme la première faille spécifique à MCP de cette liste. Wiz a publié l'exploitation qu'elle a observée : depuis le 7 juillet 2026, ses honeypots ont enregistré des requêtes portant des jetons Bearer d'un seul caractère qui sondaient des points de terminaison de listage de modèles, et Wiz ne décrit aucune autre utilisation de la faille.

Rien de comparable n’existe pour la clé par défaut. Aucune victime n’est nommée, aucune passerelle n’est identifiée comme ayant été prise de contrôle via sk-1234, et aucune télémétrie ne montre les 294 hôtes utilisés. L’entrée d’archive ne consigne aucun préjudice réel, ce qui est une affirmation sur les preuves plutôt que sur le mécanisme : l’exposition a été mesurée, et non constatée en cours d’utilisation.

Deux autres éléments sont souvent classés aux côtés de ceux-ci et ne désignent pas la même chose. CVE-2026-42271, l’exécution de commandes via deux points de terminaison de test MCP, est la faille de LiteLLM que des attaquants ont réellement exploitée pour exécuter du code ; les honeypots de Wiz ont enregistré son installation d’un mineur de cryptomonnaie. Le cas d’août 2026 publié par Microsoft, dans lequel un intrus a lu les variables d’environnement d’un conteneur de passerelle, récupéré la clé maîtresse, les clés des fournisseurs et une chaîne de connexion à une base de données, puis copié des enregistrements des tables de modèles et de clés virtuelles de LiteLLM, illustre ce que vaut une passerelle compromise plutôt qu’un nouveau mode d’accès ; The Hacker News rapporte que Microsoft évalue le point d’entrée comme étant la chaîne CVE-2026-42271.

La position des mainteneurs est qu’une clé maîtresse manquante est une erreur de configuration, pas une vulnérabilité.

La politique de sécurité de LiteLLM est explicite. Elle cite parmi les problèmes hors périmètre « les attaques qui nécessitent une mauvaise configuration lors de l'installation (par exemple, ne pas définir de master_key dans la configuration du proxy) », et indique que ces problèmes sont explicitement hors périmètre et ne sont pas considérés comme des vulnérabilités. Wiz parvient à une conclusion compatible en partant de la direction opposée lorsqu'il qualifie le comportement de pass-through de vraisemblablement conforme au fonctionnement prévu.

Cette position a été mise à l’épreuve publiquement. Le 15 août 2026, un chercheur a ouvert le ticket GitHub #37054, signalant qu’un proxy dont LITELLM_MASTER_KEY n’est pas défini authentifie n’importe quelle valeur de clé et que le fichier docker-compose livré n’en définit aucune. Le ticket a été fermé 30 minutes plus tard, et son unique commentaire provient du même compte : il cite l’instruction de la politique de sécurité selon laquelle les signalements doivent passer par des rapports privés de vulnérabilité plutôt que par des tickets publics, s’excuse d’avoir déposé publiquement et indique que le rapport complet était en cours de soumission via la voie des avis de sécurité. Aucune réponse d’un mainteneur n’apparaît dans le fil, de sorte que le dossier montre le rapporteur retirant le rapport public plutôt qu’une réponse du projet à celui-ci. Rien de public ne consigne ce qu’il est advenu de la soumission privée.

Aucune déclaration publique de BerriAI défendant ou révisant cette position sur le rapport de septembre n'a été trouvée pour cet article. La réponse visible de l'entreprise se trouve dans ses notes de version et ses fichiers de configuration plutôt que dans un texte rédigé.

L’application est intervenue le 3 octobre, vingt-quatre jours après le rapport.

Les deux failles de code ont été corrigées bien avant le rapport. La chronologie de divulgation de Wiz consigne l’exécution du code de garde-fou signalée le 18 février 2026 et corrigée le 25 février dans la v1.82.0, le contournement MCP corrigé le 25 avril dans la v1.84.0, l’exploitation observée le 7 juillet, les identifiants CVE publiés le 8 juillet et l’inscription au catalogue le 2 septembre. Les artefacts de version portent des dates plus tardives que celles des correctifs : l’index des paquets indique la v1.82.0 au 1er mars 2026 et la v1.84.0 au 14 mai, ce qui marque le moment où chaque correctif est devenu installable plutôt que celui où il a été intégré. Deux registres de versions de l’éditeur datent les mêmes correctifs plus tard que cette chronologie. La version v1.82.0-stable sur GitHub porte la date du 11 mars 2026 et le paquet 1.82.0 sur PyPI celle du 1er mars ; la v1.84.0 est datée du 14 mai 2026 sur les deux. Rien de publié n’explique cet écart, et cela n’a pas d’importance pour l’argument, puisque chacune de ces dates tombe plusieurs mois avant le rapport de septembre. Les deux avis GitHub ajoutent encore une troisième date : ils ont été publiés le 30 juin 2026, trois semaines avant les identifiants CVE que Wiz dit avoir été diffusés le 8 juillet.

Ce qu'aucune de ces versions n'avait corrigé, c'était la valeur par défaut. Wiz a signalé qu'au 9 septembre, la clé maître était toujours définie sur sk-1234 lors de l'installation de LiteLLM via Docker Compose ou pip install, et The Hacker News a confirmé que le guide d'installation utilisait encore cette valeur ce jour-là. Le changement est intervenu avec la v1.104.0, mise en ligne sur le Python Package Index le 3 octobre 2026, dont les notes de version l'indiquent comme un changement incompatible : le proxy refuse désormais de démarrer avec une clé maître non définie, vide ou publiquement connue, en nommant la source de la valeur incorrecte dans l'erreur de démarrage et en affichant une commande qui en génère une sécurisée. Une entrée associée consigne une modification visant à cesser de promouvoir une valeur de clé maître faible et publiquement connue dans les configurations et exemples livrés, et le fichier docker-compose de la branche principale du projet ne définit plus du tout de clé.

Voilà la séquence qu’il vaut la peine de conserver. Le code a été corrigé au printemps. La valeur qui rendait ces correctifs insuffisants est restée dans les instructions d’installation jusqu’en octobre, et ce n’est qu’alors que le logiciel a commencé à la refuser. Aucun des deux correctifs n’exigeait que l’autre attende.

Ce qui n’a pas changé, c’est la route de transit vers le service de métadonnées d’instance. Elle ne porte toujours aucune CVE ni correctif, car le projet considère les administrateurs comme dignes de confiance. La liste de remédiation de Wiz relève donc surtout du travail de l’opérateur : une clé maître forte et unique, une revue des garde-fous enregistrés suivie d’un redémarrage du processus pour effacer le code conservé en mémoire, un audit des points de terminaison de transit avec une sortie réseau de conteneurs restreinte, et des rôles IAM à privilège minimal. Aucun de ces quatre éléments ne s’obtient par une simple mise à niveau.

Ce que le dossier n’établit pas

• Aucune réplication indépendante de l’analyse de 3 074 hôtes n’a été trouvée. Les 9,6 % correspondent à la mesure de Wiz, et toutes les autres mentions de ce chiffre le reprennent de manière attributive.

• Aucun chiffre d’exposition actuel n’existe. Le suivi d’août a trouvé plus de 85 000 instances, dont Wiz affirme qu’elles sont principalement des pots de miel ou des déploiements de test et ne peuvent pas être comparées au décompte de février.

• Aucune victime. Rien dans le dossier ne nomme une passerelle, un opérateur ou un compte cloud compromis via la clé par défaut, et l’exploitation que Wiz documente concerne le contournement MCP plutôt que sk-1234.

• Aucune preuve que les 294 hôtes aient été utilisés. Le scan a testé s’ils s’authentifieraient, ce qui est une affirmation plus faible que de montrer que quelqu’un l’a réellement fait.

• Pas de gravité établie pour la faille du garde-fou. Wiz et les mainteneurs décrivent le même comportement et l'évaluent très différemment, et la différence porte sur les privilèges que chacun suppose déjà détenus par l'attaquant.

Wiz est également un fournisseur de sécurité cloud qui vend de la détection pour cette catégorie d’exposition, et le rapport se conclut par une section sur la manière dont ses propres produits identifient les déploiements LiteLLM, les versions vulnérables et les instances fantômes. C’est un contexte pour lire la section sur la remédiation, et non une raison de minimiser une mesure dont les détails techniques sont corroborés par les avis des mainteneurs eux-mêmes.

La partie de l’enregistrement qui voyage au-delà de LiteLLM est l’espace entre deux dates. La vulnérabilité a été corrigée au printemps. La valeur par défaut qui faisait que la vulnérabilité comptait pour un inconnu était encore imprimée dans les instructions d’installation en septembre, et le logiciel n’a commencé à la refuser qu’en octobre. Les opérateurs qui ont modifié la chaîne n’ont jamais eu à attendre quoi que ce soit de tout cela.