Transport STDIO de MCP : le choix de conception devenu 11 CVE et 200 000 agents exposés

De quoi s’agit-il ?

Le 16 avril 2026, OX Security a publié The Mother of All AI Supply Chains, divulgation coordonnée d’une vulnérabilité systémique dans le Model Context Protocol (MCP) — le standard ouvert qu’Anthropic a introduit en 2024 pour permettre aux LLM de dialoguer avec des outils externes. Le défaut n’est pas dans une implémentation isolée. Il est dans le transport STDIO lui-même, le mécanisme par défaut utilisé par MCP pour connecter un agent à un outil local : le champ command de la configuration d’un serveur MCP est transmis tel quel à subprocess et exécuté sur l’hôte, sans validation, sans assainissement, sans frontière d’exécution entre configuration et commande.

OX a scanné l’écosystème et identifié environ 7 000 serveurs MCP publiquement accessibles dont le transport STDIO est actif. Par extrapolation, les chercheurs estiment environ 200 000 instances vulnérables au total dans les déploiements auto-hébergés, et plus de 150 millions de téléchargements dans la chaîne d’approvisionnement concernée. La divulgation a été reprise le jour même par The Register, fin avril par VentureBeat et The Hacker News, puis par le Cloud Security Alliance dans une note de recherche datée du 23 avril 2026. Anthropic a confirmé le comportement et refusé de modifier le protocole, qualifiant l’exécution STDIO de « secure default » et plaçant l’assainissement des entrées sous la responsabilité du développeur.

En six semaines, le défaut a engendré au moins onze CVE dans des frameworks aval — dont CVE-2026-30623 chez LiteLLM, plus des advisories chez LangFlow, Flowise, LangChain et Cursor.

Comment ça fonctionne

Le transport STDIO de MCP est un mince habillage autour de subprocess. Un agent lit une configuration de serveur contenant un champ command, la transmet à StdioServerParameters, et lance le processus nommé pour échanger des messages JSON-RPC via l’entrée et la sortie standards. Le contrat est : « la commande doit être un lanceur de confiance ». En pratique, le champ est traité comme une donnée par toutes les couches en amont qui le manipulent.

# Structure conceptuelle — uniquement illustrative, pas un exploit.
# Source : advisory OX Security, note CSA.

# Configuration de serveur MCP consommée par l'agent :
#   transport: "stdio"
#   command:   "<chaîne contrôlée par l'attaquant>"
#   args:      [...]
#
# Atteint StdioServerParameters dans chaque SDK officiel
# (Python / TypeScript / Java / Rust) et est lancé comme
# sous-processus sur l'hôte de l'agent. Aucun allowlist,
# pas d'échappement shell, aucune sandbox par défaut.

OX a identifié quatre familles d’exploitation sur ce primitif. La première est l’injection de commande non authentifiée via les interfaces web des frameworks — LangFlow comme LiteLLM exposaient des endpoints de création de serveur MCP où la valeur command arrivait inchangée jusqu’au lanceur STDIO. La deuxième est le contournement d’allowlist : les frameworks qui tentaient de restreindre command à un ensemble connu (Flowise, Upsonic) livraient des allowlists défaites par chemins absolus, smuggling d’arguments ou interpréteurs alternatifs. La troisième est la distribution de paquets malveillants via les registres MCP : OX a soumis un paquet de démonstration bénin à onze registres ; neuf l’ont accepté sans revue de sécurité, ce qui signifie qu’un attaquant peut publier un serveur dont la command est hostile par construction. La quatrième est l’altération de configuration : tout utilisateur autorisé à ajouter un serveur MCP à une passerelle multi-tenant peut, par définition, exécuter du code sous l’identité de la passerelle.

Le point essentiel est qu’aucune de ces voies ne requiert de casser le protocole. Le transport STDIO fonctionne exactement comme documenté ; la surface d’attaque est l’écart entre « le développeur assainira sa configuration » et ce que font les déploiements réels.

Pourquoi c’est important

La question STDIO de MCP est l’exemple public le plus clair, aujourd’hui, d’un différend protocole contre produit en sécurité LLM. La position d’Anthropic — STDIO est un transport, pas une frontière de privilège ; le développeur est responsable de la commande exécutée — est défendable au niveau du protocole. La réalité aval, documentée par OX dans des déploiements en production, est que des centaines de milliers d’installations ont repris le défaut documenté et l’ont intégré directement à une infrastructure exposée sur le web.

Trois conséquences sont déjà visibles. Premièrement, le même primitif continue de générer des CVE. Chaque framework qui enveloppe MCP et accepte une entrée utilisateur près du champ command est à une route de configuration de l’exécution de code à distance, et il faut s’attendre à d’autres entrées sur la liste d’ici la fin de l’année. Deuxièmement, les registres MCP sont désormais un vecteur crédible de chaîne d’approvisionnement — un attaquant n’a plus besoin de compromettre le poste d’un développeur pour faire pénétrer du code dans son agent ; soumettre un paquet à un registre permissif suffit. Troisièmement, la réponse du protocole crée un précédent : un défaut publié qui livre par défaut une exécution de code arbitraire, charge à chaque implémenteur de la sécuriser, ce n’est pas une posture qu’aucun autre standard de transport n’avait fait passer ces dernières années.

Pour les équipes qui exploitent aujourd’hui des frameworks d’agents auto-hébergés, la conséquence pratique est que la configuration d’un serveur MCP fait partie de votre surface d’attaque et doit être traitée comme du code.

Défenses

Il n’y a pas de correctif unique à installer. Les mitigations se déploient sur quatre couches, toutes applicables sans attendre Anthropic.

La première couche est une allowlist de commandes, sur le modèle du MCP_STDIO_ALLOWED_COMMANDS de LiteLLM (livré en v1.83.6-nightly, stabilisé en v1.83.7). L’ensemble autorisé doit être la liste minimale de lanceurs connus dont votre environnement a réellement besoin — par exemple npx, uvx, python, python3, node, docker, deno — et la vérification doit rejeter les chemins absolus, le smuggling d’arguments et les interpréteurs indirects. La liste fait le travail évident, mais elle impose aussi une revue de code à chaque ajout demandé.

La deuxième couche est l’isolation du processus. Les serveurs MCP doivent tourner dans une sandbox — conteneur sans montage du système de fichiers hôte, utilisateur non privilégié, filtres syscall, pas de réseau sortant sauf nécessité explicite, identité distincte de celle de la passerelle. Si la commande lancée se révèle hostile, le rayon d’explosion s’effondre sur la sandbox.

La troisième couche est l’hygiène des registres. Traitez les registres de paquets MCP comme vous traitez npm ou PyPI : épinglez les versions, privilégiez les paquets signés, exploitez un miroir interne pour la production, relisez les champs command et args avant installation, et n’activez jamais la mise à jour automatique des serveurs MCP sur une passerelle de production.

La quatrième couche est le contrôle réseau et d’accès. Les passerelles MCP, instances n8n, tableaux LangFlow et outils similaires n’ont rien à faire sur une IP publique sans authentification. Placez-les derrière un VPN ou un reverse proxy authentifié, journalisez chaque invocation d’outil MCP avec l’identité appelante, et alertez sur tout changement de configuration de serveur MCP.

Une étape distincte et peu coûteuse consiste à s’abonner à la cascade. Les onze CVE déjà publiées partagent une cause racine commune ; tout framework dont vous dépendez et qui enveloppe MCP est candidat à la prochaine entrée. Suivez les advisories d’OX Security, la note de la CSA Labs, et directement les éditeurs concernés.

État des lieux

Élément	Référence	Date	Notes
Divulgation initiale OX Security	« The Mother of All AI Supply Chains »	2026-04-16	~7 000 serveurs publics, ~200 000 extrapolés
Couverture presse	The Register	2026-04-16	Position « by design » d’Anthropic rapportée
Synthèse de la cascade	The Hacker News	2026-04	« Anthropic MCP Design Vulnerability Enables RCE »
Note de recherche	Cloud Security Alliance Labs	2026-04-23	Cadrage chaîne d’approvisionnement systémique
Advisory LiteLLM	CVE-2026-30623	2026-04	Patché en v1.83.7-stable ; allowlist ajoutée
Advisory étendue	Suivi OX Security	2026-05	11 CVE catalogués, quatre familles d’exploitation
Position d’Anthropic	Mainteneurs de la spec MCP	2026-04	Aucune modification du protocole prévue

Le transport STDIO de MCP est aujourd’hui l’exemple public canonique d’un choix de conception qui survit à chaque correctif individuel. Traitez le champ de configuration comme du code non fiable, pas comme une donnée — et supposez que la cascade n’est pas terminée.