Menu

LiteLLM au KEV : votre gateway IA est un plan de contrôle, traitez-la comme votre IAM

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
2 min de lecture
⏱️
Temps de lecture estimé
~4 minutes

Un Bearer « x » suffisait à ouvrir une session MCP authentifiée sur LiteLLM. La CVE-2026-59822 est entrée au catalogue KEV de la CISA le 2 septembre, et c’est la troisième faille LiteLLM exploitée listée en 2026. Les gateways LLM et les serveurs MCP sont devenus aussi centraux que l’IAM cloud, sans en avoir encaissé les quinze ans d’incidents. Voici ce que je reprendrais tout de suite à l’IAM.

Votre gateway LLM détient les clés de chaque fournisseur de modèles, les budgets par équipe, les journaux de prompts et, depuis un an, l’accès des agents aux serveurs MCP qui touchent la base clients ou le dépôt de code. Elle décide qui parle à quel modèle et quel agent appelle quel outil. C’est un plan de contrôle, au même titre que l’IAM cloud, sauf que l’IAM a eu quinze ans de fuites S3 et de rôles *:* pour apprendre, et que les gateways IA rattrapent ça en dix-huit mois.

Ce que disent les sources

Sur l’endpoint MCP Streamable HTTP de LiteLLM, quand la validation de la clé échouait, un repli « OAuth2 passthrough » pouvait la remplacer par une identité vide. Un en-tête Authorization inventé suffisait alors pour atteindre les outils MCP configurés (GHSA-7488-6r32-c95q). La faille est corrigée en 1.84.0, notée 8.8 en CVSS 4.0 côté GitHub et 8.2 en CVSS 3.1 au NVD.

La CISA l’a ajoutée au catalogue KEV le 2 septembre 2026, et Wiz a vu passer dans ses honeypots des sondes avec Authorization: Bearer x, oui, un seul caractère. On l’a beaucoup présentée comme la « première faille MCP au KEV » ; ce n’est pas tout à fait exact, la CVE-2026-42271, ajoutée en juin, visait déjà les endpoints de test MCP de LiteLLM.

Au menu de la version abonnés

Au Menu, la suite de l’analyse :

  • le schéma du chemin d’authentification qui échoue « ouvert », et la vérification faite dans le flux JSON du KEV ;
  • le tableau des trois failles LiteLLM listées au KEV en 2026, chacune mise en regard d’une leçon de l’IAM (refus par défaut, authentification séparée de l’autorisation, coffre des identifiants) ;
  • le chaînage avec Starlette « BadHost » et ce qu’il dit de la segmentation entre plan d’administration et plan de données ;
  • l’analyse STRIDE et le tableau d’impact ;
  • les sept mitigations.
📬 Analyse complète réservée aux abonnés Substack
Le schéma, le test, le STRIDE et les mitigations partent d'abord aux abonnés Substack, avant d'être publiés intégralement ici.

📚 Quelques références pour aller plus loin

LinkedIn Reddit Substack