LiteLLM : une passerelle sur dix garde la clé d'exemple

Ce qui se passe

Wiz Research a publié le 9 septembre un rapport sur LiteLLM, la passerelle open source que beaucoup d'équipes placent entre leurs applications et les fournisseurs de modèles. Sur un scan Shodan de février, 3 074 instances exposées ont été trouvées ; 294 acceptaient sk-1234, la clé d'administration donnée en exemple dans le guide d'installation. Parmi elles, 191 n'avaient aucune clé configurée, et avant 1.82.0-stable une passerelle sans clé maître accordait les droits administrateur à toute requête entrante.

Au 9 septembre, le guide d'installation utilise toujours sk-1234, au-dessus d'un commentaire demandant de la remplacer.

Pourquoi ça compte

La clé maître fait deux choses à la fois : c'est l'identifiant administrateur, et c'est l'interrupteur qui active l'authentification. Un administrateur de passerelle voit les clés d'API de chaque fournisseur configuré, chaque prompt et chaque réponse en transit, et les serveurs MCP raccordés. Les clés volées suffisent à faire tourner des modèles sur la facture de la victime, ce que Wiz appelle du LLMjacking.

Wiz montre ensuite le chemin vers le compte cloud. Un administrateur peut créer un endpoint pass-through, une route qui relaie vers l'URL de son choix. Cette URL n'est pas filtrée contre les adresses privées, localhost ou le service de métadonnées. Pointer une route vers ce service renvoie les identifiants IAM de la machine ; IMDSv2 ne protège pas, car tout en-tête préfixé x-pass- est transmis au relais sans le préfixe, ce qui permet d'envoyer ceux qu'IMDSv2 exige. LiteLLM considère que l'administrateur est de confiance : pas de CVE, pas de correctif, et sa politique de sécurité classe les erreurs de configuration hors périmètre.

Les quatre failles, elles, sont corrigées

CVE-2026-59822 est déjà exploitée : Wiz l'a vue sur ses pots de miel depuis le 7 juillet, et la CISA l'a inscrite au catalogue KEV le 2 septembre avec une échéance fédérale au 16 septembre. CVE-2026-42271, chaînée avec la faille Starlette CVE-2026-48710, a servi sans identifiants à installer un mineur de cryptomonnaie. Microsoft a documenté en août un cas où les attaquants ont lu la clé maître, les clés fournisseurs et la chaîne de connexion dans l'environnement du conteneur, puis copié les tables de clés virtuelles dans PostgreSQL.

Comment s'y prendre

1. Remplacer la clé maître par une valeur longue et aléatoire. Aucune mise à jour n'est nécessaire. Vérifier d'abord si une salt key distincte est définie : la procédure de rotation change, et une erreur rend les identifiants stockés illisibles.
2. Passer en 1.84.0 ou plus, qui couvre toutes les failles du tableau.
3. À défaut, bloquer au reverse proxy /mcp/, POST /mcp-rest/test/connection et POST /mcp-rest/test/tools/list, ainsi que POST /guardrails/test_custom_code ; restreindre POST /guardrails et PUT /guardrails/{guardrail_id} aux administrateurs.
4. Passer en revue les endpoints pass-through, limiter le trafic sortant du conteneur, et donner à la charge de travail le rôle IAM le plus étroit possible.
5. En cas de doute sur une intrusion : vérifier la liste des guardrails, redémarrer le processus pour purger le code en mémoire, puis faire tourner clés fournisseurs, clé maître et identifiants de base. Une mise à jour ne retire ni un guardrail enregistré par un attaquant ni une clé SSH ajoutée.

À retenir

Le chiffre de février n'a pas d'équivalent actuel : un second scan en août a compté plus de 85 000 instances, mais Wiz y voit surtout des pots de miel et des systèmes de test. Ce qui reste vrai, c'est la consigne de Microsoft : traiter une passerelle IA comme un coffre de secrets de niveau zéro.

Source : Nearly 1 in 10 Exposed LiteLLM Gateways Accepted the Example "sk-1234" Admin Key