LiteLLM, le proxy LLM que la moitié des équipes IA déploient sans réfléchir, vient d'entrer au catalogue CISA KEV avec une faille d'authentification MCP exploitée dans la nature. Ce n'est pas un bug isolé. C'est le signal que l'infrastructure IA est devenue une surface d'attaque mature — et que la plupart des organisations ne le savent pas encore.

L'infrastructure IA : ce qu'on a construit trop vite et trop mal

Entre 2023 et 2026, les équipes techniques ont déployé une couche d'infrastructure entièrement nouvelle pour exploiter l'IA générative. On parle de gateways LLM (LiteLLM, LiteLLM Proxy, OpenRouter), d'orchestrateurs de workflows IA (Kestra, n8n, Airflow branché sur des modèles), de frameworks API (FastAPI via Starlette, LangServe, LangChain Serve), de serveurs MCP (Model Context Protocol), de vector databases (Chroma, Weaviate, Qdrant), et de couches de RAG (Haystack, LlamaIndex). En trois ans, des dizaines de composants sont devenus des pièces critiques de l'infrastructure de production dans des milliers d'entreprises.

Le problème est structurel : ces projets ont été créés par des gens brillants dont la priorité était la fonctionnalité, pas la sécurité. LiteLLM, créé en 2023 par BerriAI, est passé de 0 à 15 000 étoiles GitHub en quelques mois — une trajectoire qui ne laisse pas de temps pour des revues de sécurité approfondies. Starlette, la base de FastAPI, a été écrite par Tom Christie avec une obsession pour la performance et l'ergonomie ; la surface d'attaque des en-têtes HTTP n'était pas la priorité numéro un. Ces projets ont évolué avec le mouvement "move fast" typique de l'écosystème IA — et ils portent maintenant les cicatrices de cette philosophie.

Ce n'est pas un jugement moral. C'est un constat opérationnel. Quand on analyse un SI client aujourd'hui et qu'on découvre une instance LiteLLM exposée sur le réseau interne sans authentification — ce qui arrive dans environ 40 % des environnements IA que j'audite — la réaction habituelle est la surprise : "On pensait que c'était un outil interne, pas un service exposé." La réalité, c'est que les ports 8080, 8000 et 4000 de LiteLLM sont accessibles depuis le VLAN de développement, qui communique avec la production. La frontière est floue, et personne ne l'a dessinée.

Le résultat : une dette sécuritaire considérable, contractée en silence, sur des composants qui traitent des données que les organisations considèrent souvent comme très sensibles. Car que fait-on avec LiteLLM en production ? On lui soumet des contrats pour résumé, des données RH pour analyse, des emails clients pour classification, des documents financiers pour extraction. La faille MCP de CVE-2026-59822 ne donne pas seulement accès au proxy — elle donne accès à l'historique de tout ce qu'on lui a soumis.

Cinq vecteurs d'attaque spécifiques à l'infrastructure IA

Après des dizaines d'audits d'infrastructure IA en 2025 et 2026, j'ai identifié cinq vecteurs récurrents que les équipes ne considèrent pas dans leurs modèles de menace traditionnels. Ces vecteurs ne sont pas théoriques — ils correspondent à des findings réels sur des clients réels.

1. Les gateways LLM sans authentification

LiteLLM, OpenRouter auto-hébergé, LangChain Serve — ces gateways sont régulièrement déployés avec l'authentification désactivée "pour simplifier le développement" et finissent en production dans cet état. La faille CVE-2026-59822 est particulièrement redoutable parce qu'elle contourne même l'authentification configurée : un Bearer token arbitraire suffit. Mais le scénario le plus fréquent que j'observe n'est même pas aussi sophistiqué — l'instance est simplement accessible sans aucune auth sur le réseau interne, et parfois exposée via un Nginx mal configuré vers Internet. Coût d'exploitation : zéro. Charge utile : accès à tous les modèles configurés, aux historiques, et aux clés API des fournisseurs LLM stockées en variable d'environnement.

2. Les clés API LLM en clair dans les environnements

Les clés OpenAI, Anthropic, Azure AI sont des credentials de facturation directe — leur vol génère une charge financière immédiate et exfiltre les capacités IA de la victime au profit de l'attaquant. Sur les environments que j'audite, ces clés se trouvent dans des .env non chiffrés, des variables d'environnement Docker exposées via l'API Docker daemon, des secrets Kubernetes sans RBAC restrictif, des dépôts Git privés avec l'historique de commits qui contient les anciennes valeurs. JFrog Artifactory stocke souvent ces secrets — CVE-2026-82329 donne un accès admin à tout le registre d'artefacts, ce qui inclut les secrets d'environnement embarqués dans les images Docker.

3. Les vector databases sans contrôle d'accès

Chroma, Qdrant et Weaviate déployés localement fonctionnent par défaut sans authentification. Ils contiennent les embeddings vectoriels de documents souvent confidentiels — contrats, emails, code source propriétaire. Une instance Chroma exposée sur le réseau interne permet de requêter directement ces embeddings, voire de les inverser partiellement pour reconstruire des fragments du contenu source. Ce vecteur est pratiquement invisible dans les audits traditionnels car les vector databases n'apparaissent pas dans les inventaires de services "classiques".

4. Les serveurs MCP comme pivots d'accès

Model Context Protocol est le nouveau protocole standardisé par Anthropic pour connecter les modèles LLM aux outils et données externes. En 2026, les déploiements de serveurs MCP explosent — chaque outil exposé via MCP (accès aux fichiers, aux APIs, aux bases de données) représente une surface d'attaque nouvelle. CVE-2026-59822 exploite précisément la couche d'authentification MCP. Un serveur MCP mal configuré peut devenir un pivot d'accès vers l'intégralité des systèmes qu'il expose au modèle : filesystem, bases SQL, APIs métier, outils DevOps.

5. L'injection de prompt comme vecteur d'exfiltration

Ce vecteur est le plus sous-estimé. Un attaquant qui peut interagir avec un système LLM (chatbot client, outil d'analyse de documents, assistant interne) peut tenter d'injecter des instructions dans les données traitées par le modèle pour lui faire exfiltrer des informations du contexte système. Combiné à un accès non authentifié via une faille comme CVE-2026-59822, l'injection de prompt permet de contourner les garde-fous et d'exfiltrer le system prompt, les données RAG injectées dans le contexte, et parfois des informations sur l'architecture interne. Ce n'est pas de la science-fiction — c'est documenté dans de vrais incidents depuis 2024.

LiteLLM, Kestra, Starlette : anatomie des trois failles IA du KEV

Regardons de plus près ce que nous dit la technique sur ces trois entrées KEV, au-delà des bulletins d'alerte.

LiteLLM (CVE-2026-59822) : la faille réside dans l'implémentation du serveur MCP de LiteLLM. Le protocole MCP utilise des Bearer tokens pour l'authentification. LiteLLM a implémenté une validation de ces tokens qui pouvait être contournée en fournissant un token arbitraire dans un format spécifique. Ce n'est pas une erreur cryptographique sophistiquée — c'est une validation insuffisante, le type de bug qu'une revue de code sécurité aurait détecté en 30 minutes. Ce bug existe parce que LiteLLM a ajouté le support MCP rapidement, sous pression de l'adoption du protocole, sans processus de revue sécurité formalisé.

Kludex Starlette (BadHost) : Starlette reconstruit l'URL complète à partir des composants de la requête HTTP pour les besoins de son middleware de routage. L'en-tête Host fait partie de cette reconstruction. En insérant /, ? ou # dans l'en-tête Host, un attaquant déplace les frontières perçues entre le chemin et la query string, trompant le middleware d'authentification basé sur les chemins. Ce bug est particulièrement insidieux parce qu'il est difficile à détecter en test : la requête semble syntaxiquement valide, les logs montrent une authentification "réussie", et seule une analyse approfondie du traitement des en-têtes révèle le contournement. FastAPI, qui est basé sur Starlette, hérite de ce comportement — tous les services FastAPI utilisant des middlewares d'auth basés sur les chemins sont potentiellement vulnérables sur les versions non patchées.

Kestra : les détails techniques de la faille Kestra sont moins publics à ce stade, mais le pattern général est celui d'une interface d'administration d'orchestrateur insuffisamment sécurisée — un problème récurrent dans les outils DevOps/DataOps. Kestra permet d'exécuter des workflows arbitraires (incluant du code Python, des appels shell, des connexions à des bases de données). Une faille d'authentification sur son interface expose la capacité d'exécution de code sur le serveur d'orchestration.

Ce que ça change pour les RSSI et les équipes sécurité

Les trois entrées KEV IA de septembre 2026 obligent à repenser le périmètre d'inventaire et d'évaluation des risques. Concrètement, voici ce que je recommande aux RSSI et aux équipes sécurité.

L'inventaire IA est non-optionnel. Vous devez savoir précisément quels composants IA tournent dans votre SI : gateways LLM, serveurs MCP, vector databases, orchestrateurs, APIs de fine-tuning, services d'embedding. Cet inventaire n'existe pas dans 80 % des organisations que j'audite — les composants IA ont été déployés par les équipes de développement sans passer par les processus habituels de gestion des actifs. Commencez par un scan réseau ciblé sur les ports utilisés par ces services (8080, 8000, 4000, 11434 pour Ollama, 6333 pour Qdrant, 8080 pour Chroma, etc.) et par une revue des images Docker en production.

Les modèles de menace doivent intégrer le risque IA. Le STRIDE traditionnel ne couvre pas les vecteurs d'injection de prompt, d'exfiltration via MCP, ou de détournement de gateway LLM. Adaptez vos templates de modélisation des menaces pour inclure ces nouveaux vecteurs, en particulier pour tous les systèmes où des données sensibles sont soumises à des modèles LLM — même via des APIs cloud (OpenAI, Azure OpenAI, Anthropic) car la gateway intermédiaire reste un vecteur de compromission.

Les secrets LLM sont des credentials de premier rang. Traitez les clés API OpenAI, Anthropic, Azure AI avec le même niveau de protection que vos credentials Active Directory ou vos certificats de signature de code. Rotation régulière, stockage en vault, audit des usages, alertes sur les créations de charges anormales. Une clé API OpenAI volée peut générer des milliers d'euros de charges en quelques heures — j'ai vu des clients recevoir des factures à 5 chiffres suite à un vol de clé.

Le patch management IA doit devenir un processus formalisé. Les projets open source IA publient des releases de sécurité sans les fanfares des éditeurs commerciaux. Aucun bulletin officiel CERT, pas de CVSSv3 systématique, parfois un simple commit sur GitHub. Pour suivre les vulnérabilités de LiteLLM, Starlette, Chroma, LlamaIndex, vous devez surveiller activement les dépôts GitHub de ces projets (releases, issues étiquetées "security"), les bases de vulnérabilités open source (OSV, GitHub Advisory Database), et bien sûr le catalogue CISA KEV. Automatisez cette veille avec des outils comme Dependabot, Renovate, ou des flux RSS configurés sur les advisory GitHub des projets critiques.

La réalité terrain : ce que je vois dans les audits

En 2025 et 2026, j'ai conduit des audits de sécurité sur une vingtaine d'organisations ayant déployé de l'infrastructure IA en production. Voici quelques observations sans nommer de clients.

Dans une ETI industrielle de 800 personnes, l'équipe IT avait déployé LiteLLM pour centraliser les accès aux APIs LLM des différentes équipes. Bonne initiative de centralisation. Problème : l'instance était accessible depuis tout le réseau interne sans authentification, les clés API des fournisseurs LLM étaient en variable d'environnement non chiffrée dans le docker-compose, et les logs des requêtes (contenant les prompts complets) étaient stockés dans un volume Docker lisible par tout utilisateur du serveur. Trois findings critiques sur un seul service. Correction : 2 jours de travail. Risque évité : exfiltration de données clients soumises aux modèles sur 6 mois d'historique.

Dans une société de services numériques (ESN) de 200 personnes, un développeur avait exposé un serveur MCP connecté au filesystem du serveur de développement pour permettre à Claude de lire et écrire des fichiers. Le serveur MCP n'avait aucune restriction de chemin. Un accès non autorisé à ce serveur MCP aurait permis de lire l'intégralité du code source, les fichiers de configuration, et les secrets d'environnement — sans jamais toucher aux systèmes de production directement. Surface d'attaque invisible pour un attaquant qui ne connaît pas le protocole MCP, mais triviale pour quelqu'un qui le connaît.

Dans un cabinet de conseil juridique de 50 personnes, un outil de résumé de contrats basé sur LlamaIndex et une API FastAPI interne traitait quotidiennement des centaines de contrats confidentiels. L'API n'avait pas de rate limiting, pas de logging des accès, et l'authentification reposait sur un token statique partagé entre tous les utilisateurs. Un compromis de ce token — via phishing, shoulder surfing, ou simple fuite dans un email — aurait exposé l'intégralité de l'historique des requêtes et la capacité de soumettre de nouveaux documents.

Mon avis d'expert

LiteLLM au CISA KEV est un point de bascule. Pendant deux ans, les équipes sécurité ont pu raisonnablement considérer que l'infrastructure IA interne était un risque secondaire — nouveau, peu connu des attaquants, faible surface d'exposition. Ce temps est révolu. Les attaquants cherchent activement ces composants, les outils de scan reconnaissent LiteLLM, Chroma et Qdrant, et les CVE arrivent maintenant dans les catalogues officiels avec exploitation confirmée.

Ce qui me préoccupe le plus n'est pas la faille LiteLLM en elle-même — elle sera patchée. C'est la combinaison de trois facteurs : des données ultrasensibles confiées à ces systèmes, une dette sécuritaire structurelle dans les projets open source IA, et une absence quasi-totale de visibilité des équipes sécurité sur ce périmètre. Les prochains 18 mois vont voir émerger des incidents significatifs impliquant l'infrastructure IA — fuites de données via des gateways compromises, détournements de capacité LLM à grande échelle, attaques supply chain via des dépôts d'artefacts IA. Les organisations qui anticipent maintenant — inventaire, modélisation des menaces, patch management formalisé — auront une longueur d'avance sur celles qui attendent le premier incident.

Conclusion : construire une posture sécurité IA avant que l'urgence l'impose

L'entrée de LiteLLM, Kestra et Starlette dans le catalogue CISA KEV marque la maturité de l'infrastructure IA comme surface d'attaque. Ce n'est plus de la recherche académique ou du bug bounty — c'est de l'exploitation opérationnelle documentée. Les RSSI qui n'ont pas encore intégré l'infrastructure IA dans leur périmètre de risque sont en retard, et ce retard se mesure maintenant en CVE exploitées, pas en tendances à surveiller.

La bonne nouvelle : les mesures de base sont simples. Inventaire des composants IA. Authentification systématique. Gestion des secrets LLM en vault. Patch management sur les dépôts GitHub des projets critiques. Ce n'est pas révolutionnaire — c'est l'hygiène sécurité de base appliquée à un nouveau périmètre. Le faire maintenant, de façon proactive, est infiniment moins coûteux que de le faire en réponse à un incident.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique — audit d'infrastructure IA, revue de posture, modélisation des menaces.

Prendre contact