Contexte et portée de l’enquête

Wiz Research a interrogé Shodan en février 2024 et a identifié 3 074 instances publiques de LiteLLM, le gateway open‑source qui relaie les requêtes d’applications vers les fournisseurs de modèles IA. Parmi ces passerelles, 294 ont accepté la clé d’administration fournie dans le guide d’installation, soit près de 10 %. Dans 191 cas, aucune clé n’était définie, ce qui signifie que n’importe quel client pouvait s’authentifier. Un second balayage en août a recensé plus de 85 000 instances, mais la majorité semble être des honeypots ou des environnements de test, rendant le chiffre non comparable.

Mécanisme de la clé maître et risques associés

La clé maître, exemplifiée par 

sk-1234
, joue deux rôles : identifiant administrateur et commutateur d’authentification. Avant la version 1.82.0‑stable, le lancement d’une passerelle sans clé maître octroyait des droits d’administration complets à chaque requête entrante. L’administrateur peut ainsi accéder aux API‑keys des fournisseurs, intercepter chaque prompt et réponse, et invoquer le Model Context Protocol (MCP) pour appeler des outils internes. La clé donne également accès aux permissions cloud du workload, permettant le « LLMjacking », c’est‑à‑dire l’exécution de modèles facturés au compte victime.

Failles de code et escalade vers le cloud

Wiz a signalé deux vulnérabilités critiques. CVE‑2026‑59821, décrite par le chercheur comme une exécution de code post‑authentification avec privilèges root, a reçu un score CVSS de 2.1 par le projet LiteLLM, alors que les chercheurs le classifient comme haute gravité. La faille réside dans les points d’entrée qui créent ou modifient des guardrails : avant 1.82.0, ils contournaient le sandbox et les contrôles de pattern, autorisant l’injection de Python exécuté dans le conteneur. Une autre vulnérabilité, CVE‑2026‑40217, permettait d’échapper au sandbox via des techniques de bytecode, affectant les versions 1.81.8 à <1.83.10. Le conteneur Docker officiel exécute le processus proxy en tant que root, ce qui rend l’escalade possible. Des CVE supplémentaires (59822, 42271, 48710) ont été exploités pour ouvrir des sessions MCP ou exécuter des commandes host, comme le montre le cas Microsoft où un mineur de cryptomonnaie a été installé.

Recommandations de mitigation

La mise à jour vers la version 1.84.0 ou supérieure corrige l’ensemble des failles répertoriées. En parallèle, il faut remplacer immédiatement la clé maître par une valeur aléatoire longue ; cette opération ne nécessite pas de mise à jour logicielle, mais il faut vérifier le paramètre de « salt key » afin d’éviter la corruption des clés stockées. Les administrateurs doivent restreindre les routes pass‑through en bloquant les adresses privées, localhost et les points de terminaison de métadonnées cloud, ou au minimum appliquer IMDSv2 avec les en‑têtes x-pass-* correctement filtrés. Enfin, la politique de sécurité du projet doit être révisée pour inclure les configurations par défaut comme des vecteurs d’attaque, car elles sont actuellement exclues du champ de responsabilité.