CVE-2026-59822 : LiteLLM MCP auth bypass exploité KEV CISA

Les faits

Le 2 septembre 2026, la CISA (Cybersecurity and Infrastructure Security Agency) a ajouté CVE-2026-59822 à son catalogue des Vulnérabilités Exploitées Connues (KEV), confirmant une exploitation active dans la nature. Cette vulnérabilité affecte BerriAI LiteLLM, l'une des passerelles API LLM (Large Language Model) open source les plus populaires du marché, utilisée par des milliers d'organisations pour centraliser et gérer leurs appels aux APIs de grands modèles de langage tels que GPT-4, Claude, Gemini, Azure OpenAI, Mistral et d'autres. Le score CVSS de 8.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) reflète la gravité d'une faille exploitable sans authentification depuis Internet, avec impact maximal sur les trois piliers de la sécurité.

La vulnérabilité réside dans le mécanisme d'authentification de l'endpoint MCP (Model Context Protocol) Streamable HTTP de LiteLLM, introduit pour permettre aux agents IA et aux outils compatibles MCP de se connecter à LiteLLM et d'utiliser ses capacités de routage vers plusieurs LLMs. Dans les versions antérieures à 1.84.0, LiteLLM implémente un mécanisme de fallback OAuth2 dans ce chemin d'authentification qui est défectueux : lorsqu'une clé LiteLLM fournie dans l'en-tête Authorization échoue à la validation, le système bascule sur un chemin de traitement alternatif OAuth2 passthrough qui remplace l'objet d'authentification par un objet UserAPIKeyAuth() vide, c'est-à-dire sans clé valide, plutôt que de rejeter la requête avec une erreur HTTP 401 Unauthorized.

Concrètement, un attaquant n'a qu'à inclure n'importe quel Bearer token dans l'en-tête HTTP de sa requête vers l'endpoint MCP (Authorization: Bearer valeur_quelconque) pour déclencher le chemin de fallback OAuth2 et obtenir un accès complet aux outils MCP configurés dans l'instance LiteLLM cible. Cette exploitation ne nécessite aucune connaissance préalable de clés API valides, aucun brute-force, et aucune condition technique complexe. La faille est reproductible avec une seule requête HTTP correctement formatée, ce qui en fait une cible idéale pour des outils d'exploitation automatisés.

La criticité de cette vulnérabilité va bien au-delà d'un simple accès non autorisé à une API. LiteLLM, en tant que proxy IA central, est fréquemment configuré avec des accès à des APIs LLM de production (clés API OpenAI, Anthropic, Google, Azure, etc.), des connexions à des bases de données vectorielles, des outils MCP configurés avec des accès système tels que lecture de fichiers, exécution de requêtes SQL, navigation web et appels à des APIs externes, ainsi que des permissions de génération de contenu au nom de l'organisation. Un attaquant exploitant CVE-2026-59822 hérite potentiellement de l'ensemble de ces accès et peut les utiliser pour exfiltrer des données, générer du contenu malveillant à grande échelle, ou consommer des ressources LLM à des coûts considérables pour l'organisation cible.

Selon les informations publiées par The Hacker News et relayées par la CISA, les attaquants exploitant activement cette vulnérabilité déploient principalement des reverse shells — des connexions en retour vers leur infrastructure de commande et contrôle (C2) — et des mineurs de cryptomonnaie sur les serveurs hébergeant LiteLLM. Ces usages indiquent que des groupes opportunistes automatisent le scan et l'exploitation de toutes les instances LiteLLM exposées sur Internet, dans une démarche de compromission à grande échelle similaire aux campagnes ciblant Metabase, SonicWall SMA1000, ou Kestra OSS observées en 2026.

BerriAI a corrigé la vulnérabilité dans la version 1.84.0 de LiteLLM en modifiant le chemin de traitement de l'authentification MCP pour rejeter explicitement les requêtes dont la validation de clé échoue, quel que soit le chemin d'authentification emprunté. La correction supprime le comportement de fallback OAuth2 qui substituait un objet d'authentification vide à une clé valide, remplaçant ce mécanisme défaillant par un rejet strict avec erreur 401. Aucune mesure de mitigation alternative officielle n'a été publiée pour les versions non patchées — la mise à jour vers 1.84.0 est la seule solution définitive recommandée.

Le contexte d'adoption du protocole MCP est important pour comprendre la surface d'attaque. Lancé fin 2024 par Anthropic et rapidement adopté par l'écosystème IA, le Model Context Protocol permet aux agents IA d'accéder à des outils et ressources externes via une interface standardisée. LiteLLM a intégré la compatibilité MCP pour permettre aux agents utilisant n'importe quel LLM via sa passerelle d'accéder à des outils tiers. Cette intégration rapide, dans un contexte d'adoption massive et d'une certaine précipitation à commercialiser des fonctionnalités IA, a conduit à une implémentation insuffisamment sécurisée du mécanisme d'authentification — un pattern récurrent dans l'écosystème IA en 2025-2026 où la vélocité de développement prime souvent sur la revue de sécurité.

La CISA a imposé aux agences fédérales américaines relevant du FCEB (Federal Civilian Executive Branch) de corriger cette vulnérabilité avant le 16 septembre 2026. Cette date limite s'applique aux entités gouvernementales américaines, mais constitue un signal d'urgence universel pour toutes les organisations ayant déployé LiteLLM dans leurs environnements de production ou de développement exposés à Internet. La présence au catalogue KEV CISA indique une exploitation active confirmée avec impact réel sur des systèmes en production, et justifie un traitement en urgence absolue quelle que soit la politique de patch habituelle de l'organisation.

Impact et exposition

Toute instance BerriAI LiteLLM antérieure à la version 1.84.0 avec l'endpoint MCP Streamable HTTP exposé sur Internet est directement vulnérable. Les déploiements les plus exposés sont ceux accessibles sans pare-feu applicatif ni liste blanche d'IP, ce qui est courant dans les environnements de développement, de démonstration, et dans les déploiements cloud où LiteLLM est configuré comme backend d'un assistant IA accessible à des utilisateurs externes. Les organisations ayant déployé LiteLLM via Docker ou des plateformes cloud PaaS sans restreindre l'accès à l'endpoint MCP sont particulièrement exposées.

L'impact d'une exploitation réussie dépend des outils MCP et des clés API configurés dans l'instance LiteLLM compromise. Dans le pire des cas, l'attaquant accède à des clés API LLM de production avec des quotas élevés représentant des coûts potentiels de dizaines de milliers d'euros en génération de contenu malveillante, à des outils MCP avec des accès système ou base de données, et à des données d'entreprise transitant par la passerelle. L'installation de reverse shells et de cryptominers observée dans les exploitations actuelles représente le cas d'usage opportuniste minimal — des acteurs plus sophistiqués peuvent viser des objectifs bien plus dommageables comme le vol de propriété intellectuelle, la compromission de chaînes de traitement IA, ou l'accès à des systèmes en aval via les outils MCP configurés.

La détection d'une exploitation est possible via l'analyse des logs d'accès à l'endpoint MCP de LiteLLM. Des requêtes avec des Bearer tokens invalides ou génériques ayant abouti à des réponses HTTP 200 (succès) plutôt que HTTP 401 (non autorisé) sont caractéristiques de l'exploitation de cette faille. Une anomalie dans la consommation des API LLM configurées — pic soudain de tokens générés, requêtes depuis des IPs inattendues — peut également indiquer une exploitation active en cours.

Recommandations immédiates

• Mettre à jour BerriAI LiteLLM vers la version 1.84.0 ou supérieure via pip install litellm==1.84.0 ou la mise à jour de l'image Docker correspondante
• Si la mise à jour immédiate est impossible : désactiver ou bloquer l'accès à l'endpoint MCP Streamable HTTP via une règle de pare-feu ou de proxy inverse
• Révoquer et régénérer toutes les clés API LLM (OpenAI, Anthropic, Azure, etc.) configurées dans LiteLLM si une exploitation est suspectée
• Analyser les logs d'accès à l'endpoint /mcp pour identifier des accès non autorisés antérieurs à la correction
• Vérifier la présence de processus inattendus (reverse shells, mineurs de cryptomonnaie) sur les serveurs hébergeant LiteLLM
• Mettre en place une liste blanche d'IPs sources autorisées à accéder à l'endpoint MCP si le service doit rester exposé temporairement