Les passerelles d'IA deviennent la surface d'attaque — l'inscription au KEV de LiteLLM et le chemin par les clés, MCP et le cloud
Le contournement d'authentification MCP de BerriAI LiteLLM (CVE-2026-59822) est entré dans le catalogue KEV de CISA, et Microsoft signale des attaquants qui utilisent des passerelles LiteLLM pour livrer XMRig. Une recherche de Wiz a trouvé qu'environ 1 sur 10 d'environ 3,000 instances publiques acceptaient la clé par défaut sk-1234 ou fonctionnaient sans authentification. Nous examinons ce que signifie le fait que l'infrastructure d'IA soit un coffre d'identifiants.
Cet article a été traduit par une machine.
En septembre 2026, CISA a ajouté le contournement d'authentification MCP de BerriAI LiteLLM, CVE-2026-59822, à son catalogue Known Exploited Vulnerabilities (KEV) (le 2 septembre, selon la chronologie de Wiz). La faille permet à un jeton Bearer arbitraire d'établir une session authentifiée valide sur le point de terminaison MCP Streamable HTTP de LiteLLM, et elle est apparue aux côtés de 6 autres failles exploitées — dont SonicWall SMA 1000 et Sangoma Switchvox — dans la mise à jour du KEV de début septembre (selon The Hacker News). LiteLLM est une passerelle d'IA open source qui détient les clés d'API de chaque fournisseur de LLM configuré ; selon l'estimation de Wiz, elle est présente dans environ 1/3 des environnements cloud.
Les faits : (1) La recherche de Wiz (publiée le 9 septembre) a trouvé que, sur environ 3,000 instances LiteLLM exposées à Internet, environ 9.6 % acceptaient la clé maître par défaut sk-1234 ou n'exigeaient aucune authentification. Dans les instances sans authentification configurée, chaque utilisateur recevait PROXY_ADMIN par défaut, et atteignait ainsi la fonctionnalité d'administration sans identifiants (corrigé depuis). (2) Avec des droits d'administration, un attaquant peut utiliser la fonction de point de terminaison pass-through pour relayer des requêtes vers des URL internes arbitraires — y compris le service de métadonnées AWS — et le mécanisme de transfert d'en-têtes x-pass- défait l'exigence de jeton de session d'IMDSv2, ce qui permet le vol d'identifiants IAM cloud. (3) En septembre, Microsoft a signalé des attaquants qui enchaînent CVE-2026-42271 et CVE-2026-48710 (le contournement d'authentification Starlette « BadHost ») pour pénétrer des passerelles LiteLLM et livrer un mineur XMRig au moyen d'un binaire ELF (selon The Hacker News). Les attaques contre des instances RAGFlow exposées ont, pendant ce temps, produit des clés de fournisseur LLM volées et des métadonnées, plutôt qu'un rançongiciel.
Analyse (séparée des faits) : ce que ces récits montrent, c'est que les passerelles d'IA ont dépassé le stade du « LLMjacking » — dépenser le budget d'API de quelqu'un d'autre — pour devenir un chemin d'intrusion cloud à part entière. LiteLLM exécute du Python côté serveur à chaque requête d'inférence, peut relayer des requêtes vers des URL internes arbitraires, et se connecte à des outils externes via MCP. Ce n'est pas seulement un coffre de clés ; c'est un pont vers le réseau interne, avec une capacité d'exécution. Des actifs que les défenseurs préfèrent ranger sous un principe de conception « c'est de l'IA, gardez-le en interne » deviennent, pour les attaquants, un chemin à plusieurs étapes vers les clés, l'IAM et les API internes, derrière un seul contournement d'authentification. L'écart structurel entre des valeurs par défaut conçues pour l'expérience du développeur (sk-1234, PROXY_ADMIN lorsqu'aucune configuration n'est faite) et le déploiement en production mérite d'être nommé comme tel.
Implications défensives : (1) Si vous exécutez LiteLLM, mettez d'abord à jour vers v1.84.0 ou ultérieur (correctif de CVE-2026-59822) et vers v1.83.7 ou ultérieur (correctif de CVE-2026-42271), ainsi que vers Starlette 1.0.1 ou ultérieur ; confirmez que la clé maître par défaut a été changée et que l'instance n'est pas exposée à Internet. (2) Faites tourner toutes les clés d'API de fournisseur stockées comme si elles étaient compromises dès que l'exposition est confirmée, et fixez des plafonds de dépense pour limiter le dommage lorsqu'une clé s'en va. (3) Traitez les fonctions qui portent une exécution de code arbitraire ou un relais d'URL arbitraire — MCP, points de terminaison pass-through — comme des permissions de niveau agent, à inventorier séparément et à désactiver par défaut. (4) Auditez les autres passerelles d'IA et les orchestrateurs de LLM avec le même regard : identifiants par défaut, fonctionnalité d'administration exposée, relais d'URL interne. Ceci est notre analyse, pas une guidance de l'éditeur.
Les faits de cet article sont tirés principalement de la recherche de Wiz (https://www.wiz.io/blog/off-guard-breaking-litellm-from-authentication-bypass-to-cloud-compromise), de la version de correctif de BerriAI LiteLLM (https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable) et du catalogue KEV de CISA (https://www.cisa.gov/known-exploited-vulnerabilities-catalog), avec le compte rendu de The Hacker News en source secondaire (https://thehackernews.com/2026/09/cisa-adds-5-actively-exploited.html et https://thehackernews.com/2026/09/cisa-adds-seven-exploited-flaws-as.html) ; la date du 2 septembre pour le KEV suit la chronologie de Wiz. Les sections d'analyse sont tenues séparées du compte rendu factuel. À noter que les dénombrements d'instances et la part des environnements cloud sont des estimations qui dépendent du moment et de la méthode de mesure.