L’essentiel
Près d’une passerelle IA LiteLLM exposée sur dix accepte encore la clé maîtresse par défaut documentée sk-1234 – et cette seule chaîne suffit à prendre le contrôle de la passerelle et à atteindre le compte cloud qui se trouve derrière. Wiz Research a analysé environ 3 074 instances LiteLLM accessibles depuis Internet repérées sur Shodan en février 2026 : 294 d’entre elles acceptaient la clé d’exemple du guide d’installation de LiteLLM, et 191 n’avaient aucune clé maîtresse définie, si bien qu’elles acceptaient n’importe quelle valeur. LiteLLM est la passerelle open source que de nombreuses équipes placent entre leurs applications et les fournisseurs de modèles payants : la clé qu’elle stocke ouvre donc chaque secret API en aval.
La lecture pratique : une passerelle IA n’est pas un confort de développeur, c’est un coffre-fort d’identifiants doté d’un accès réseau. Si votre organisation en exploite une, la parade durable est la même discipline que pour tout service porteur de secrets – clés uniques, aucune exposition publique, rôles cloud au moindre privilège et correctifs rapides. C’est précisément la posture que nous intégrons dès le premier jour dans le développement d’agents IA et de passerelles, plutôt que de l’ajouter après qu’un scan a trouvé la clé par défaut.
Ce que Wiz a découvert
LiteLLM est une passerelle IA open source très répandue – le logiciel qu’une entreprise place entre ses propres applications et les fournisseurs de modèles qu’elle paie, afin que chaque appel LLM passe par un point unique pour le routage, la gestion budgétaire, la journalisation et la gestion des clés. Cette conception rend la passerelle pratique, mais en fait aussi un point de concentration des secrets : elle stocke les clés API d’OpenAI, d’Anthropic, d’AWS Bedrock, de Google et de tout ce que l’organisation utilise par ailleurs. Qui contrôle la passerelle les contrôle toutes. Comme les équipes en déploient de plus en plus en construisant des agents IA et des copilotes internes, la passerelle est discrètement devenue une infrastructure de production – exactement le type de composant que nos ingénieurs classent comme critique pour la sécurité dans tout projet d’agent IA.
Dans un rapport publié le 10 septembre 2026, Wiz Research décrit l’analyse des déploiements LiteLLM exposés sur Internet qu’il a pu identifier. Sur environ 3 074 instances repérées sur Shodan en février 2026, 294 – près d’une sur dix – acceptaient sk-1234, la clé maîtresse d’exemple qui figure dans la documentation de LiteLLM. Dans 191 de ces 294 cas, les exploitants n’avaient défini aucune clé maîtresse, si bien que la passerelle acceptait n’importe quelle valeur. Un balayage ultérieur, en août 2026, a recensé des dizaines de milliers d’instances supplémentaires, dont beaucoup semblaient être des déploiements de test jetables ; les chiffres de février constituent la base prudente et clairement exposée.
Le détail dérangeant : il ne s’agit pas d’un zero-day exotique. C’est un identifiant d’exemple documenté, copié depuis un guide d’installation et jamais modifié, sur un service joignable depuis l’Internet ouvert. Au 9 septembre 2026, le guide de LiteLLM affichait toujours sk-1234 au-dessus d’un commentaire invitant les exploitants à le remplacer par une longue valeur aléatoire avant toute utilisation réelle – une consigne qu’au vu de ces chiffres une part significative des déploiements ignore.
Comment une clé par défaut mène à la compromission du cloud
Ce qui transforme une valeur par défaut oubliée en intrusion complète, c’est que la clé maîtresse LiteLLM remplit deux fonctions à la fois. Elle est l’identifiant administrateur du proxy, et aussi le secret HS256 qui signe les jetons de session. Un attaquant qui connaît la clé ne se contente donc pas de se connecter : il peut émettre des jetons valides pour n’importe quel utilisateur et forger des sessions arbitraires sur toute la passerelle, sans aucune modification de configuration. Lorsque la clé est une valeur imprimée dans une documentation publique, la « connaître » est trivial.
À partir de cet accès administrateur, Wiz a déroulé la chaîne comme le ferait un attaquant. D’abord, la passerelle livre toutes les clés API de fournisseurs de modèles qu’elle stocke – les identifiants payants de chaque éditeur de LLM, prêts à être détournés ou revendus. Ensuite, et c’est pire, les chercheurs ont atteint les identifiants IAM cloud de la machine qui héberge la passerelle : des points d’accès pass-through sans validation d’URL permettent de diriger une requête vers le service de métadonnées cloud à l’adresse 169.254.169.254 et d’exfiltrer des identifiants IAM temporaires – y compris sur des instances protégées par IMDSv2, par manipulation d’en-têtes. À ce stade, l’incident ne concerne plus une passerelle, mais le compte cloud qui se trouve derrière.
Deux vulnérabilités identifiées précisent le tableau. CVE-2026-59822 (CVSS 8.8) est un contournement d’authentification dans le traitement du Model Context Protocol par LiteLLM : un mécanisme de repli défaillant considère comme authentifiée une requête portant n’importe quel jeton bearer – même Authorization: Bearer a –, ce qui ouvre un accès MCP sans authentification. Elle a été corrigée dans la v1.84.0 le 25 avril 2026, puis ajoutée au catalogue Known Exploited Vulnerabilities de la CISA après une exploitation réelle. CVE-2026-59821 est une exécution de code après authentification : le code de guardrail personnalisé passe par exec/compile sans bac à sable, ce que Wiz a utilisé pour exécuter des commandes en root ; elle a été corrigée dans la v1.82.0 le 25 février 2026. L’éditeur juge ce problème de guardrail de faible gravité, une appréciation à mettre en regard d’un shell root démontré.
Ce que cela change pour les équipes en France
Au-delà du nom du produit, trois leçons durables demeurent. Premièrement, votre passerelle IA est un coffre-fort d’identifiants : traitez-la comme tel. Dans la course au déploiement d’agents et de copilotes en 2026, beaucoup d’équipes ont monté un proxy LLM comme une simple « tuyauterie » sans lui appliquer le modèle de menace réservé à une base de données. Or il détient chaque clé fournisseur et, comme le montre cette étude, offre un chemin vers votre cloud. La même posture sécurisée par défaut que pour vos bases de production – secrets uniques, aucune exposition Internet par défaut, rôles au moindre privilège – doit s’appliquer à votre couche IA et à la plateforme cloud et DevOps qui l’héberge.
Deuxièmement, les valeurs par défaut sont la plus vieille faille du monde, et l’infrastructure IA vient de le réapprendre. Mots de passe par défaut et clés d’exemple vident des serveurs depuis des décennies ; la seule nouveauté est que la machine vulnérable est une passerelle IA. Tout composant dont le guide de démarrage contient un identifiant littéral exige un contrôle automatisé strict garantissant que la valeur d’exemple n’atteint jamais la production – dans la CI, dans vos modèles de déploiement et dans des scans externes réguliers de ce que vous exposez réellement.
Troisièmement, des clés fournisseurs divulguées et un rebond vers le cloud constituent un événement de conformité, pas seulement un souci d’exploitation. Pour les équipes européennes, l’exfiltration non autorisée d’identifiants et toute donnée personnelle ou réglementée transitant par la passerelle relèvent pleinement des exigences du RGPD, de NIS2 et de DORA en matière de contrôle d’accès et de remédiation rapide et documentée. Pour les équipes qui travaillent avec des clients américains de la santé ou de la finance, la même exposition renvoie aux obligations HIPAA et SOC 2. Savoir quels services IA internes sont joignables depuis Internet – et pouvoir prouver qu’ils utilisent des identifiants uniques et des rôles au moindre privilège – est le contrôle sur lequel auditeurs et régulateurs vous interrogeront en premier.
Que faire maintenant
- Définir une clé maîtresse forte et unique – et faire tourner les clés fournisseurs. Remplacez
sk-1234ou toute valeur d’exemple documentée par une longue valeur aléatoire, et renouvelez chaque clé API de fournisseur de modèles que la passerelle a stockée, en partant du principe qu’elle a peut-être déjà fuité. - Mettre LiteLLM à jour vers la dernière version. Allez au-delà des correctifs de CVE-2026-59822 (v1.84.0) et CVE-2026-59821 (v1.82.0), et suivez les avis de sécurité du projet sur les problèmes MCP et guardrails associés.
- Retirer la passerelle de l’Internet public. Un proxy LLM ne devrait être joignable que depuis des sous-réseaux de confiance ou derrière un VPN ou un proxy zero trust. Si l’accès public n’est pas une exigence ferme, supprimez-le – cela suffit à neutraliser le risque des scans de masse.
- Réduire le rayon d’impact dans le cloud. Restreignez le trafic sortant des conteneurs pour que la passerelle ne puisse pas joindre le point de métadonnées
169.254.169.254, appliquez des rôles IAM au moindre privilège à l’hôte et privilégiez des mécanismes restreints comme IRSA plutôt que des rôles d’instance trop larges. - Inclure l’infrastructure IA dans les tests de sécurité. Passerelles, bases vectorielles et environnements d’exécution d’agents sont régulièrement exclus des évaluations alors qu’ils détiennent les clés les plus sensibles. Ajoutez-les à votre prochain test d’intrusion, vérifiez les configurations de guardrails et redémarrez les processus pour effacer tout code injecté en mémoire.
Questions fréquentes
Qu’a découvert Wiz sur les passerelles LiteLLM ?
Dans un rapport publié le 10 septembre 2026, Wiz Research a analysé environ 3 074 passerelles LiteLLM accessibles depuis Internet, repérées sur Shodan en février 2026 : 294 – environ une sur dix – acceptaient sk-1234, la clé maîtresse d’exemple du guide d’installation de LiteLLM. Dans 191 de ces cas, aucune clé maîtresse n’était définie, si bien que la passerelle acceptait n’importe quelle clé. LiteLLM étant placé entre les applications et les fournisseurs de modèles payants, sa clé maîtresse ouvre chaque secret fournisseur en aval.
Pourquoi la clé maîtresse LiteLLM est-elle si dangereuse ?
La clé maîtresse par défaut est à la fois l’identifiant administrateur et le secret HS256 qui signe les jetons de session. Quiconque détient sk-1234 inchangée peut forger des sessions utilisateur arbitraires et obtenir un accès administrateur complet sans toucher à la configuration. Wiz a ensuite montré qu’il était possible de lire chaque clé API de fournisseur de modèles sur le serveur et d’atteindre les identifiants IAM cloud de l’hôte via le service de métadonnées de l’instance – une seule chaîne divulguée suffit à compromettre le compte cloud.
Quelles CVE LiteLLM sont en cause et sont-elles corrigées ?
CVE-2026-59822 (CVSS 8.8) est un contournement d’authentification MCP où n’importe quel jeton bearer – même « Bearer a » – est accepté ; elle est corrigée dans la v1.84.0 (25 avril 2026) et figure au catalogue Known Exploited Vulnerabilities de la CISA. CVE-2026-59821 est une exécution de code après authentification via du code de guardrail sans bac à sable, corrigée dans la v1.82.0 (25 février 2026). Les problèmes associés CVE-2026-42271 et CVE-2026-40217 ont également été signalés. Passez à la dernière version et faites tourner les clés.
Laisser la clé par défaut n’est-il pas une simple erreur de configuration plutôt qu’une vulnérabilité ?
La politique de sécurité de LiteLLM considère l’absence de clé maîtresse comme une erreur de l’exploitant et non comme un défaut du produit, et au 9 septembre 2026 le guide affiche toujours sk-1234 au-dessus d’un commentaire demandant de la remplacer. Dans les deux cas, le résultat est identique : une passerelle largement déployée est livrée avec un identifiant d’exemple documenté que beaucoup d’équipes ne changent jamais, et cette valeur donne le contrôle total plus un rebond vers le cloud. La vraie solution : une configuration sécurisée par défaut et un contrôle strict empêchant tout secret d’exemple d’atteindre la production.
Que doivent faire dès maintenant les équipes qui exploitent LiteLLM ?
Définissez une clé maîtresse forte et unique, faites tourner chaque clé fournisseur que la passerelle a détenue et passez à la dernière version corrigée. Retirez la passerelle de l’Internet public sauf nécessité réelle, restreignez le trafic sortant des conteneurs pour bloquer le point de métadonnées cloud et appliquez des droits IAM minimaux. Vérifiez les configurations de guardrails, redémarrez les processus pour éliminer le code injecté, puis maintenez la passerelle IA dans le périmètre de vos tests de sécurité.
Sources
Wiz Research — Off Guard: Breaking LiteLLM from Authentication Bypass to Cloud Compromise
The Hacker News — Nearly 1 in 10 Exposed LiteLLM Gateways Accepted the Example “sk-1234” Admin Key
CISA — Known Exploited Vulnerabilities Catalog