CISA a ajouté CVE-2026-42271 à son catalogue Known Exploited Vulnerabilities le 8 juin 2026, confirmant une exploitation active dans la nature et donnant aux agences civiles fédérales jusqu'au 22 juin pour remédier. La vulnérabilité est une faille d'injection de commande dans LiteLLM, le projet open-source de BerryAI qui donne aux équipes une seule interface format-OpenAI devant des douzaines de model providers, déployé soit comme Python SDK soit, plus pertinent ici, comme gateway AI et proxy standalone qui gère les API keys, le tracking de coût et le routage de trafic. Si tu roules un LLM proxy en production, il y a une chance significative que ce soit LiteLLM, et c'est exactement pourquoi celui-ci matter plus que sa ligne CVSS seule le suggérerait.
Le mécanisme est spécifique et vaut d'être compris. Deux endpoints, POST /mcp-rest/test/connection et POST /mcp-rest/test/tools/list, acceptaient des configurations de serveur complètes puis spawnaient les commandes fournies comme subprocesses roulant avec les privilèges du processus proxy lui-même, sans sanitization propre de l'input. C'est de l'injection de commande textbook : l'input qui était censé décrire un serveur MCP à tester devient à la place une commande que le host exécute. L'accès initial requiert nominalement une valid proxy API key, ce qui sonne comme une barrière significative jusqu'à ce que tu lises la deuxième moitié : ce requirement peut être bypassé entièrement via CVE-2026-48710, un BadHost authentication bypass dans Starlette (le framework ASGI en dessous), qui transforme un bug authenticated-only en un bug unauthenticated pour tout déploiement qui n'a pas aussi patché Starlette. Le fix a atterri dans LiteLLM v1.83.7, qui à la fois sanitize les endpoints et ajoute un contrôle d'autorisation restreignant les MCP test endpoints aux users tenant le rôle PROXY_ADMIN.
La raison pour laquelle ceci s'élève au-dessus d'un CVE routinier c'est où LiteLLM sit dans le stack. Le proxy est le seul component qui, by design, tient les credentials pour chaque model provider que tu routes à travers : ta key OpenAI, ta key Anthropic, tes keys de cloud-inference, et souvent les secrets pour n'importe quoi d'autre auquel le proxy est wired. L'exécution de commande sur ce host n'est donc pas un événement contenu, c'est un accès immédiat au tas de credentials le plus concentré dans ton infrastructure AI, plus un foothold pour bouger latéralement dans tout ce que ces credentials atteignent. Le writeup help-net est blunt sur la chaîne d'impact : exécution de commande arbitraire, vol de credentials et secrets de model-provider, et mouvement latéral dans les systèmes AI connectés. Et le contexte le rend pire, c'est la deuxième vulnérabilité LiteLLM weaponisée en un seul mois après un incident de mai 2026, et BerryAI a aussi souffert une attaque supply-chain de mars 2026 via des packages PyPI malicieux. La couche gateway est activement sondée, et les attaquants ont remarqué que c'est là que les keys vivent.
Lundi matin, les actions ne sont pas subtiles et elles ne sont pas optionnelles si tu self-host LiteLLM. Premièrement, upgrade vers v1.83.7 ou plus tard aujourd'hui, c'est celui qui ferme vraiment le trou. Deuxièmement, si tu peux pas upgrade immédiatement, bloque l'accès réseau aux endpoints /mcp-rest/test/connection et /mcp-rest/test/tools/list à ton reverse proxy ou load balancer comme mesure intérimaire. Troisièmement, rotate chaque credential que le proxy a touché, sur l'assumption que si t'étais exposé tu devrais traiter les keys comme compromises, provider keys, connector secrets, n'importe quoi dans l'environnement du proxy. Quatrièmement, restreins l'exposition réseau du proxy à des segments de confiance plutôt que de laisser les surfaces admin et test atteignables depuis l'internet ouvert, qui est la configuration qui transforme ça d'une mauvaise journée en breach. Et patche Starlette aussi, parce que CVE-2026-48710 c'est ce qui enlève le prérequis API-key, et une défense qui dépend de l'attaquant n'ayant pas le bypass n'est pas une défense. Si tu tracks le thread plus large de agent-security, c'est la version concrète de l'avertissement qui se bâtit dans la research, plus les couches gateway et runtime deviennent infrastructure critique, plus elles deviennent la cible, et le LLM proxy est maintenant démonstrablement sur la ligne de front.