LiteLLM CVE-2026-47101→40217 : d'un compte limité à l'admin et au RCE

De quoi s’agit-il ?

Le 16 juin 2026, Obsidian Security a divulgué publiquement une chaîne de trois vulnérabilités dans LiteLLM, la passerelle IA open source très largement déployée. Enchaînées, elles forment un chemin CVSS 9.9 qui mène d’un utilisateur peu privilégié par défaut jusqu’au rôle proxy_admin, puis à l’exécution de code à distance sur l’hôte de la passerelle. Les trois CVE :

• CVE-2026-47102 — élévation de privilèges par absence d’autorisation au niveau du champ sur /user/update et /user/bulk_update. Le champ user_role n’est pas protégé contre les écritures contrôlées par l’appelant : tout utilisateur atteignant ces routes peut se promouvoir proxy_admin.
• CVE-2026-47101 — contournement d’autorisation : un non-admin peut créer ou modifier une clé virtuelle dont les allowed_routes sont persistés tels quels, lui accordant l’accès à des routes — y compris réservées aux admins — qu’il ne devrait jamais détenir.
• CVE-2026-40217 — évasion du bac à sable du garde-fou « code personnalisé ». Des routes accessibles à l’admin compilent et exécutent du Python fourni par l’admin dans un bac à sable basé sur exec() qui ne le confine pas réellement, d’où une exécution de code côté serveur.

Selon Obsidian, la chaîne complète est corrigée dans LiteLLM v1.83.14-stable (publiée le 2 mai 2026 ; divulgation publique mi-juin). Elle est distincte du RCE via les endpoints de test MCP, CVE-2026-42271, que la CISA a ajouté à son catalogue KEV en juin 2026 — aucune entrée KEV publique n’existe pour la chaîne 47101/47102/40217 à ce jour.

Comment ça marche

La chaîne est un manuel d’échec d’autorisation, pas une attaque sur le modèle. Chaque maillon retire une barrière :

1. Contourner l’autorisation de route (47101). LiteLLM fait confiance aux allowed_routes fournis par l’appelant sur les endpoints de gestion de clés et les stocke verbatim. Un compte peu privilégié crée une clé virtuelle référençant des routes interdites.
2. Devenir admin (47102). En atteignant /user/update (ou la variante en masse), l’attaquant écrit directement le champ sensible user_role — s’auto-promouvant proxy_admin, ce qui débloque l’accès total aux utilisateurs, équipes, clés, modèles et historique des prompts.
3. Exécuter du code (40217). En tant qu’admin, l’attaquant atteint la voie de compilation/test du garde-fou et exécute du Python dans un bac à sable défaillant, obtenant un RCE sur le processus de la passerelle.

Aucun payload n’est reproduit ici, et aucun n’est nécessaire pour saisir la leçon : une écriture de « configuration » qui touche un rôle ou une route est une décision d’autorisation, or LiteLLM en traitait plusieurs comme de simples mises à jour de champ. La cause racine récurrente est une porte de route qui consulte l’état d’une clé contrôlée par l’utilisateur comme octroi de repli, ce qui inverse le modèle d’autorisation.

Pourquoi c’est important

Une passerelle IA n’est pas un routeur passif — c’est une infrastructure de plan de contrôle. Une fois la chaîne aboutie, Obsidian note que l’attaquant peut atteindre des secrets de niveau hôte comme LITELLM_MASTER_KEY, LITELLM_SALT_KEY et DATABASE_URL, ainsi que les identifiants fournisseurs pour OpenAI, Anthropic, Gemini, Bedrock, Azure et tout autre backend configuré. D’une seule position, la passerelle devient coffre à secrets, courtier d’autorisation et homme du milieu entre agents et modèles.

Cette recherche démontre une conséquence plus spécifique à l’IA : une passerelle compromise peut réécrire les réponses du modèle et orienter les agents en aval — y compris les agents de code — vers des appels d’outils choisis par l’attaquant. Une prise de contrôle serveur devient alors un pivot de chaîne d’approvisionnement contre tout ce que la passerelle alimente. Si vous placez LiteLLM devant une flotte d’agents, son rayon d’impact est l’union de tous les identifiants et de toutes les actions d’agent qu’elle courtise.

Défenses

• Corrigez maintenant. Passez à LiteLLM v1.83.14-stable ou ultérieure, qui ferme la chaîne complète selon Obsidian. Vérifiez aussi être au-delà des correctifs de CVE-2026-42271 et CVE-2026-42208, suivies séparément.
• Faites tourner les secrets après exposition. Si une instance non corrigée était joignable depuis Internet, supposez la fuite. Rotation par priorité : clés API fournisseurs, LITELLM_MASTER_KEY et LITELLM_SALT_KEY, identifiants de base de données, puis réémission des clés virtuelles.
• Retirez la passerelle d’Internet. Traitez LiteLLM comme tout plan de contrôle porteur de secrets : réseau privé uniquement, derrière une entrée authentifiée. L’essentiel de l’exploitation rapide dans cet écosystème vise les instances exposées.
• Imposez l’autorisation au niveau du champ sur les écritures de « config ». Partout où une entrée utilisateur fixe user_role, allowed_routes, la propriété d’équipe ou des métadonnées de politique, traitez-la comme une opération réservée aux admins — pas une mise à jour ordinaire. Auditez tous les gestionnaires d’écriture de clés/utilisateurs.
• Confinez ou désactivez les garde-fous « code personnalisé ». Exécutez le proxy en moindre privilège, dans un conteneur sans accès au disque hôte ni au shell non strictement nécessaire, afin qu’une évasion d’exec() rapporte le moins possible à l’attaquant.
• Surveillez les appels d’outils et la sortie réseau. Alertez sur les changements de rôle en libre-service, les clés virtuelles créées avec des allowed_routes larges, et tout trafic sortant anormal de la passerelle. Une passerelle compromise pilotant des agents se traduira par des invocations d’outils inattendues.

Statut

CVE	Classe	Effet	Corrigé dans
CVE-2026-47101	Contournement d’autorisation	allowed_routes non autorisés sur clés virtuelles	v1.83.14-stable (chaîne complète)
CVE-2026-47102	Élévation de privilèges	Auto-promotion en proxy_admin via /user/update	versions < 1.83.10 affectées
CVE-2026-40217	Évasion de bac à sable du garde-fou	Exécution de code côté serveur via exec()	correctif garde-fou ; v1.83.14-stable
CVE-2026-42271 (séparée)	Injection endpoint de test MCP	RCE ; dans le KEV de la CISA	1.83.7

Le bon cadrage n’est pas « encore un RCE LiteLLM ». C’est que les passerelles IA sont désormais des plans de contrôle porteurs d’exécution, et que plusieurs de leurs frontières de privilèges étaient appliquées comme de simples champs de données. Corrigez la chaîne, faites tourner ce qu’elle pouvait atteindre, et traitez chaque écriture fixant un rôle ou une route comme la décision d’autorisation qu’elle est réellement.