LLM pipelines et MCP : la surface d'attaque que personne ne surveille

En une semaine, la CISA a ajouté trois CVE ciblant l'infrastructure IA à son catalogue d'exploits actifs — LiteLLM MCP, Kestra, Starlette. Qilin s'en sert pour déployer du ransomware. Ce n'est pas un accident : vos pipelines LLM sont devenus la surface d'attaque que personne ne surveille vraiment, et les attaquants l'ont compris avant beaucoup d'équipes sécurité.

L'infrastructure IA : une surface d'attaque en pleine explosion, sans la maturité sécurité qui va avec

En 2023, quand les équipes sécurité entendaient "déploiement IA", elles pensaient risques de prompt injection et hallucinations. En 2026, la réalité a rattrapé les modèles de menace théoriques avec une brutalité particulière : les composants techniques qui constituent l'infrastructure LLM — frameworks d'orchestration, serveurs MCP, frameworks ASGI, API gateways pour LLM — sont devenus des vecteurs d'attaque de premier rang. Non pas parce qu'ils sont intrinsèquement moins bien conçus que d'autres logiciels, mais parce qu'ils ont connu une adoption massive en un temps record, dans des organisations dont les équipes sécurité n'étaient pas préparées à évaluer ces nouvelles surfaces.

La donnée qui cristallise cette tendance : sur les sept vulnérabilités ajoutées au CISA KEV le 2 septembre 2026, trois ciblent spécifiquement l'infrastructure IA. CVE-2026-59822 dans LiteLLM MCP (bypass d'authentification sur l'endpoint MCP Streamable HTTP, CVSS 8.8), CVE-2026-49869 dans Kestra OSS (injection de commande OS dans l'orchestrateur de workflows), CVE-2026-48710 dans Starlette (HTTP request smuggling dans le framework ASGI sous-jacent à FastAPI). Ce n'est pas une coïncidence statistique — c'est le signal que les attaquants ont activement prospecté cette surface et y trouvent des vulnérabilités exploitables à grande échelle.

Le KEV n'agrège que des vulnérabilités avec preuve d'exploitation réelle dans la nature. Que trois composants IA y apparaissent simultanément dans la même mise à jour, c'est la confirmation que la prospection offensive de l'infrastructure IA est passée du stade de la recherche académique à celui des opérations criminelles organisées. Et le groupe Qilin, associé formellement à l'exploitation de CVE-2026-59822, est loin d'être un acteur amateur : c'est un opérateur RaaS sophistiqué avec des affiliés spécialisés par secteur et par technique d'intrusion.

L'anatomie d'une attaque sur pipeline LLM : ce qui se passe concrètement

Pour comprendre pourquoi l'infrastructure IA est une cible si attractive, il faut comprendre sa topologie réelle. Un pipeline LLM typique en production en 2026 ressemble à ceci : une ou plusieurs APIs frontend (souvent FastAPI sur Starlette) reçoivent les requêtes ; un composant de routage LLM (souvent LiteLLM) distribue les requêtes vers différents providers (OpenAI, Anthropic, Azure AI, modèles on-premise) ; un orchestrateur de workflows (Kestra, Airflow, Prefect) gère les pipelines de traitement ; des vector stores (Pinecone, Weaviate, Chroma) stockent les embeddings ; des bases de données classiques stockent les conversations et données métier ; et des comptes cloud hébergent l'ensemble de la stack.

Ce qui rend ce pipeline particulièrement dangereux du point de vue de l'attaquant : la concentration de credentials à haute valeur. LiteLLM gère les clés API de tous vos providers LLM. Kestra accède aux systèmes de données internes que les agents IA doivent requêter. Un accès non autorisé à ces composants donne simultanément accès à des milliers d'euros de crédits LLM pillageable ou utilisable pour des opérations offensives, aux données que l'IA traite (souvent des données métier sensibles ou des données clients), et à un point de pivot vers tous les systèmes accessibles depuis le pipeline.

La chaîne d'exploitation documentée pour CVE-2026-59822 illustre parfaitement cette réalité : exploitation du bypass d'authentification LiteLLM MCP, puis lecture de la configuration interne pour récupérer les clés API des providers LLM et les credentials de services tiers, puis pivot vers les buckets S3 ou Azure Blob accessibles depuis le même compte, puis déploiement du ransomware Qilin. Deux heures suffisent selon les analyses forensiques publiées. Ce n'est pas un scénario d'école — c'est ce qui s'est passé dans des environnements réels.

Pourquoi vos équipes sécurité sont structurellement en retard sur ces risques

Il y a une raison structurelle pour laquelle l'infrastructure IA est sous-sécurisée dans la plupart des organisations : elle a été déployée en dehors des processus sécurité habituels, souvent par des équipes qui ne sont pas familières avec les enjeux de sécurité opérationnelle.

Les pipelines LLM ont typiquement été mis en production via trois chemins : des projets PoC qui sont passés directement en production sans revue sécurité (le pipeline "temporaire" qui dure), des équipes data science ou ML ops qui ont déployé des composants Python avec les droits disponibles (souvent trop larges), ou des achats de solutions SaaS IA dont l'intégration technique a été faite rapidement sans évaluation des composants sous-jacents. Dans les trois cas, l'inventaire de l'infrastructure IA est souvent incomplet dans les référentiels sécurité, et les composants open source utilisés (LiteLLM, Kestra, Langchain, Chroma...) ne sont pas systématiquement inclus dans les processus de patch management.

La surface d'attaque IA présente également des caractéristiques qui la rendent difficile à couvrir avec les outils et méthodes traditionnels. Les composants changent rapidement — les cycles de release de LiteLLM ou de Langchain se mesurent en semaines. Les architectures sont souvent distribuées entre cloud, on-premise et SaaS, avec des flux de données complexes à cartographier. Et les frontières de confiance sont difficiles à définir précisément : un agent IA qui peut appeler des outils externes, accéder à des bases de données et envoyer des emails représente un périmètre fonctionnel étendu, difficile à modéliser avec des approches de menace classiques.

Le problème MCP : une nouvelle surface qui explose sans garde-fous

Le Model Context Protocol (MCP), standardisé par Anthropic et rapidement adopté par l'écosystème IA, mérite une attention particulière. MCP est le protocole qui permet aux LLM d'utiliser des outils externes — bases de données, APIs, systèmes de fichiers, emails, calendriers. Il est conçu pour étendre les capacités des agents IA, et son adoption a été massive en 2025-2026. Le problème de sécurité est structurel : MCP crée par design des connexions entre les agents IA et des systèmes internes ou externes. Chaque connexion MCP est un vecteur d'attaque potentiel.

CVE-2026-59822 dans LiteLLM MCP illustre ce risque concrètement. LiteLLM implémente un endpoint MCP Streamable HTTP qui permet à des clients de s'établir comme consommateurs MCP. La faille d'authentification incorrecte dans cet endpoint permet à n'importe quel client d'obtenir une session authentifiée avec un Bearer token arbitraire. Résultat : un attaquant non authentifié devient un client MCP légitime aux yeux du serveur, avec accès aux outils et données configurés pour ce serveur.

Ce type de vulnérabilité est particulièrement difficile à détecter avec les méthodes traditionnelles. Un scanner de vulnérabilité classique ne comprend pas la sémantique MCP. Les WAF n'ont pas encore de règles spécifiques pour filtrer du trafic MCP malveillant. Et les équipes sécurité qui n'ont pas été formées aux protocoles IA ne savent pas quoi chercher dans les logs de ces nouveaux composants. C'est le combo qui favorise structurellement les attaquants : nouvelle surface, outils de défense immatures, équipes peu formées.

Ce que j'observe sur le terrain : les angles morts typiques

Dans les missions d'audit que je réalise sur des environnements ayant déployé de l'IA en production, je retrouve systématiquement les mêmes angles morts.

Premier angle mort : l'inventaire incomplet. Les équipes sécurité ne savent pas avec précision quels composants IA sont en production, dans quelle version, avec quelles permissions. LiteLLM version X tourne quelque part, déployé par l'équipe data science il y a six mois, avec des credentials en dur dans un fichier de configuration versionné dans un repository Git "privé" accessible à quarante développeurs. Ce n'est pas un cas d'école — c'est ce que je vois régulièrement.

Deuxième angle mort : les secrets dans les configurations LLM. Les fichiers de configuration de LiteLLM, OpenAI SDK, LangChain contiennent quasi systématiquement des clés API en clair. Ces clés donnent accès à des comptes facturés. Un attaquant peut générer des milliers d'euros de coûts en quelques heures, ce qui expose l'organisation à des risques financiers immédiats et à des risques légaux selon l'usage qui en est fait.

Troisième angle mort : les permissions excessives des agents IA. Les agents sont configurés avec les droits les plus larges possibles pour être fonctionnels — accès à des bases de données entières plutôt qu'à des vues restreintes, accès à des systèmes de fichiers complets plutôt qu'aux seuls répertoires nécessaires. Quand un attaquant prend le contrôle d'un agent IA, il hérite de toutes ses permissions configurées.

Quatrième angle mort : l'absence de monitoring des appels LLM. Dans la quasi-totalité des organisations que j'audite, les logs d'appels LLM ne sont ni centralisés ni analysés pour détecter des comportements anormaux. Un attaquant qui exfiltre des données via des prompts d'extraction systématique ne laisse pas de traces dans les SIEM traditionnels — il faut une surveillance spécifique des APIs LLM pour le détecter.

Les actions prioritaires dans les 30 prochains jours

Face à cette surface d'attaque émergente, les organisations doivent prendre des mesures concrètes sans attendre d'avoir une stratégie IA security parfaitement formalisée — le parfait est l'ennemi du bien, surtout quand les exploits sont déjà dans le KEV.

Priorité 1 — Inventaire : cartographiez tous les composants IA en production avec leurs versions exactes. Frameworks LLM (LiteLLM, OpenAI SDK, Langchain, LlamaIndex), orchestrateurs (Kestra, Airflow, Prefect, n8n), APIs (FastAPI sur Starlette, Flask), vector stores (Chroma, Weaviate, Pinecone, Qdrant), agents IA déployés. Si vous n'avez pas cet inventaire, vous avancez à l'aveugle sur la surface la plus en croissance de votre périmètre.

Priorité 2 — Nettoyage des secrets : auditez tous les fichiers de configuration, variables d'environnement, repositories Git (y compris l'historique avec git log -p) pour trouver des clés API LLM en clair. Migrez vers un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault). Révoquez et régénérez toutes les clés potentiellement exposées — les providers LLM permettent de générer de nouvelles clés instantanément.

Priorité 3 — Réduction des permissions : appliquez le principe du moindre privilège à vos agents IA. Accès aux seules données nécessaires, avec des comptes de service dédiés, sans permissions d'administration. Un agent qui répond à des questions sur votre catalogue produit n'a pas besoin d'un accès complet à la base clients.

Priorité 4 — Monitoring : centralisez les logs d'appels LLM dans votre SIEM et définissez des alertes sur les patterns anormaux : volumes d'appels inhabituels, prompts contenant des patterns d'extraction systématique, appels depuis des IP inattendues, Bearer tokens inconnus sur les endpoints MCP. Ce monitoring n'est pas encore standard dans l'industrie — mettez-le en place avant d'en avoir besoin.

Conclusion

L'infrastructure IA est devenue une surface d'attaque de premier rang en 2026. Trois CVE dans le KEV en une mise à jour, un groupe ransomware confirmé en exploitation active, des milliers de pipelines LLM déployés sans revue sécurité complète — les conditions d'une vague d'incidents significatifs sont réunies. Les mesures de base restent accessibles et les délais de mise en oeuvre raisonnables : un inventaire rigoureux, un nettoyage des secrets, une réduction des permissions et un monitoring minimal permettent de réduire drastiquement la surface exposée. La fenêtre pour agir de manière proactive plutôt que réactive se referme progressivement — chaque semaine compte.