Près d'une passerelle LiteLLM publique sur 10 scannées par Wiz acceptait sk-1234, la clé maîtresse d'exemple de la documentation

Verdict : si votre passerelle LiteLLM est accessible depuis internet, changez sa clé maîtresse aujourd'hui, puis passez à la version 1.84.0 ou ultérieure. Changer la clé est une modification de configuration, pas une mise à jour, et cela "ferme tous les vecteurs du rapport de Wiz qui supposent de la détenir", selon la formule de The Hacker News. Notre répertoire attribue à LiteLLM la note Conditionnel, et la condition, c'est précisément ce type de discipline de sécurité : ce rapport montre pourquoi elle existe.

Ce qui s'est passé

Wiz Research a publié "Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise" le 9 septembre 2026.

Le chiffre de 9,6 % décrit l'échantillon de février, pas l'internet d'aujourd'hui. Voyez-y l'ampleur de l'habitude, pas un décompte actuel.

Le même rapport couvre des failles distinctes, chacune corrigée dans une version :

Aucune version corrective du tableau de Wiz n'est postérieure à la 1.84.0 : la 1.84.0 ou toute version ultérieure couvre donc les trois. The Hacker News en cite deux autres, CVE-2026-42271 (exécution de commandes MCP, corrigée en 1.83.7) et CVE-2026-40217 (évasion du bac à sable, corrigée en 1.83.10), que la 1.84.0 couvre également.

Pourquoi c'est important

La clé maîtresse, c'est toute la passerelle. "LiteLLM peut détenir les clés API de chaque fournisseur de LLM configuré, traiter chaque prompt et chaque réponse qui y transitent, et se connecter à des outils externes via MCP", écrit Wiz. Wiz a montré que la fonction pass-through pouvait atteindre le service de métadonnées AWS pour exfiltrer des identifiants IAM ; The Hacker News résume que, lors des tests de Wiz, la clé "a aussi atteint les identifiants IAM cloud de la machine sur laquelle tourne la passerelle." Une seule clé de passerelle divulguée met en jeu toutes les factures fournisseurs, et potentiellement le compte cloud de l'hôte.

La valeur par défaut venait de la documentation. Wiz : "La documentation de LiteLLM utilise sk-1234 comme clé maîtresse d'exemple dans les guides de démarrage rapide, les exemples Docker Compose et les tutoriels de configuration, dans toute la documentation." Au 9 septembre, le guide d'installation l'utilisait encore, au-dessus d'un commentaire demandant aux opérateurs de la remplacer, rapportait The Hacker News. Au 23 septembre, le démarrage rapide Docker de LiteLLM l'avait abandonnée et génère désormais la clé avec openssl rand -hex 32. Une passerelle montée à partir de l'ancien guide garde sk-1234 jusqu'à ce que quelqu'un la change. La politique de sécurité de LiteLLM classe les attaques qui nécessitent une erreur de configuration comme "explicitement hors périmètre." Autrement dit : c'est votre problème de configuration, et personne en amont ne corrigera une passerelle déployée à votre place.

Un second avertissement, indépendant. Le rapport sur les menaces de septembre 2026 d'Anthropic indique que "plusieurs acteurs ont été observés en train de compromettre l'implémentation de LiteLLM au sein de services wrappers d'IA" et ont utilisé l'injection de prompt "pour exfiltrer les clés API de production." Vecteur d'attaque différent, même cible.

Ce qui change pour vous

1. Remplacez sk-1234 par une clé maîtresse longue et aléatoire. Aucune mise à jour nécessaire.
2. Passez à LiteLLM 1.84.0 ou à une version ultérieure, qui couvre toutes les failles du tableau de Wiz.
3. Impossible de mettre à jour pour l'instant ? Bloquez /mcp/, POST /mcp-rest/test/connection et POST /mcp-rest/test/tools/list au niveau de votre proxy inverse ou de votre passerelle d'API. Bloquez POST /guardrails/test_custom_code, et réservez POST /guardrails et PUT /guardrails/{guardrail_id} aux administrateurs.
4. Durcissez l'hôte. Auditez les endpoints pass-through, restreignez le trafic réseau sortant du conteneur et attribuez à la charge de travail un rôle IAM à moindre privilège.
5. Si un attaquant a pu avoir accès, passez en revue la liste des garde-fous à la recherche d'entrées que vous n'avez pas créées, redémarrez le processus pour effacer le code conservé en mémoire, puis renouvelez les clés des fournisseurs, la clé maîtresse et les identifiants de la base de données.

Vous vous demandez s'il vaut la peine d'héberger vous-même une passerelle ? Voir LiteLLM vs OpenRouter : une passerelle que vous exploitez porte exactement cette charge de durcissement ; une passerelle que vous louez, non.

FAQ

Changer la clé maîtresse nécessite-t-il de mettre à jour LiteLLM ? Non. C'est une modification de configuration, et elle ferme tous les vecteurs du rapport de Wiz qui supposent de détenir la clé.

Quelle version de LiteLLM corrige les failles divulguées ? La 1.84.0 ou ultérieure couvre toutes les failles du tableau de Wiz, y compris le contournement de l'authentification MCP CVE-2026-59822.

9,6 % de toutes les passerelles LiteLLM sont-elles exposées en ce moment ? Non. Ce chiffre provient de l'échantillon de 3 074 instances analysé par Wiz en février 2026. Le scan d'août a trouvé plus de 85 000 instances, dont la plupart semblent être des honeypots ou des déploiements de test.

LiteLLM considérera-t-il la clé par défaut comme une vulnérabilité ? Non. Sa politique de sécurité classe les attaques qui nécessitent une erreur de configuration comme "explicitement hors périmètre."