VIPER-MCP : 67 CVE issues de failles de type taint sur 40 000 serveurs MCP

What is this?

Le 20 mai 2026, une équipe (Pengyu Sun, Qishu Jin, Enhao Huang, Zifeng Kang, Xin Liu, Dakun Shen et Song Li) a publié VIPER-MCP sur arXiv (cs.CR, 2605.21392). Il s’agit d’un cadre d’audit automatisé pour les serveurs Model Context Protocol (MCP) — ces petits programmes qui exposent des outils (commandes shell, requêtes HTTP, accès fichiers, requêtes base de données) à un agent LLM.

Les chiffres qui font le titre : sur un scan de 39 884 dépôts open source de serveurs MCP, VIPER-MCP a trouvé 106 vulnérabilités zero-day, a confirmé chacune d’elles par une trace d’exploitation de bout en bout, et a fait attribuer 67 identifiants CVE à ce jour. Les auteurs indiquent que toutes les découvertes confirmées ont été divulguées de façon responsable aux développeurs concernés. Nous traitons ce sujet non parce qu’un bug particulier serait inédit — ce sont des failles d’injection classiques — mais parce que la mesure quantifie un motif que l’écosystème MCP porte depuis ses débuts : une entrée en langage naturel d’agent qui parvient, non assainie, jusqu’à un sink sensible.

How it works

Une vulnérabilité « de type taint » est un chemin où une entrée contrôlée par l’attaquant (la source) atteint une opération dangereuse (le sink) sans validation suffisante au milieu. Dans un serveur MCP, la source est un argument d’outil que le modèle remplit ; le sink est ce que le gestionnaire de l’outil en fait. Quand ce gestionnaire lance un shell, ouvre une socket, construit un chemin de fichier ou assemble une requête, un argument non contraint devient injection de commande, SSRF, traversée de répertoire ou injection SQL — et comme les outils MCP s’exécutent avec les privilèges du serveur, l’état final est souvent une exécution de code à distance. C’est la même classe que les découvertes back-end MCP d’Akamai et le même franchissement de frontière que Microsoft a documenté quand les prompts sont devenus des shells.

L’apport de VIPER-MCP est de rendre cela auditable à grande échelle sans se noyer sous les faux positifs. Il combine deux passes, décrites ici au niveau de la méthode, pas du payload :

Étape                 Ce qu'elle fait
--------------------  ----------------------------------------------------------
Scan statique 2 passes  L'analyse de taint standard signale les chemins source->sink
                      candidats, puis une passe « anchor-query » ajoute la structure
                      au niveau fonction pour qu'une alerte de fichier se résolve en
                      un gestionnaire d'outil MCP précis et une chaîne d'appels concrète.
Confirmation dynamique  Une boucle guidée par rétroaction affine les prompts en langage
                      naturel vers le sink signalé. Deux mutateurs tournent
                      indépendamment : l'un corrige la dérive de sélection d'outil,
                      l'autre approfondit la pénétration de paramètre. Des graines
                      notées par fitness orientent la recherche.
Verdict               Un chemin n'est rapporté que si une trace de bout en bout atteint
                      réellement le sink — une « découverte » est donc un exploit
                      confirmé, pas un avertissement non validé.

L’intérêt méthodologique : les scanners MCP antérieurs produisaient soit des alertes statiques intriables, soit s’appuyaient sur des modèles de payloads figés qui rataient les bugs exigeant une forme d’argument spécifique ou un chemin multi-étapes. Face à deux références existantes, les auteurs rapportent un taux de 4,6 % de faux positifs et 7,7 % de faux négatifs. Aucun prompt d’exploitation n’est reproduit ici ; la référence canonique reste le papier et les enregistrements CVE attribués.

Why it matters

La couche serveur MCP est désormais une chaîne d’approvisionnement logicielle vaste et en croissance rapide, que la plupart des équipes installent plutôt qu’elles n’écrivent. Les mesures de juin 2026 chiffrent l’exposition : selon le tour d’horizon MCP d’Adversa, Censys a dénombré 12 520 services MCP accessibles depuis Internet (la plupart non authentifiés), et une étude de mesure distincte a trouvé qu’environ 40 % des serveurs distants exposent leurs outils sans aucune authentification. VIPER-MCP ajoute la dimension qualité de code : une fraction notable de ces serveurs porte aussi des failles de type taint exploitables dans ses gestionnaires d’outils.

Deux conséquences en découlent. D’abord, un serveur MCP vulnérable transforme la prompt injection en RCE. Si un attaquant peut influencer le contenu que lit un agent — une page web, un document, un commentaire — il peut l’orienter pour qu’il appelle un outil défaillant avec un argument hostile. L’agent est le vecteur de livraison ; le bug du serveur est le payload. Ensuite, 67 CVE sur 40 000 dépôts signifie que votre graphe de dépendances en contient presque certainement quelques-unes. Contrairement à un avis isolé, c’est une classe à balayer, pas une ligne à corriger une fois.

Defenses

Les correctifs sont peu spectaculaires et bien compris — l’écart, c’est que le code des serveurs MCP les saute souvent.

1. Traitez chaque argument d’outil comme une entrée non fiable. Le modèle n’est pas un appelant de confiance ; ses arguments peuvent être influencés par un attaquant via une injection indirecte. Validez type, longueur et jeu de caractères autorisé à la frontière du gestionnaire avant que la valeur n’atteigne un sink.

2. Éliminez les sinks dangereux. Évitez shell=True / les commandes construites par concaténation (passez des vecteurs d’arguments), paramétrez chaque requête base de données, résolvez et confinez les chemins de fichiers à une racine sur liste blanche, et restreignez les requêtes sortantes à une liste blanche de destinations pour bloquer le SSRF. Ne passez jamais un argument d’outil à eval/exec.

3. Exécutez les serveurs en moindre privilège et isolation. Réduisez le rayon d’impact : utilisateur dédié peu privilégié, sandbox ou conteneur, pas d’identifiants cloud ambiants, filtrage de l’egress réseau. Une RCE confinée est un incident ; non confinée, c’est une compromission.

4. Authentifiez et désexposez les serveurs distants. Mettez de l’authentification devant chaque serveur MCP distant et retirez d’Internet ceux qui n’en ont pas — le geste à plus fort impact, et celui que les comptages d’exposition montrent que la plupart des opérateurs négligent encore.

5. Auditez avant d’accorder votre confiance à un serveur tiers. Scan de taint statique (ce que VIPER-MCP automatise) plus revue des serveurs que vous chargez au démarrage. Vérifiez si l’une des 67 CVE attribuées touche vos dépendances et suivez les correctifs amont.

6. Ajoutez une couche de confiance et d’admission. Couplez ce qui précède à des propositions comme l’admission attestée de serveurs d’outils (clearance signée, listes blanches deny-by-default) et les considérations de conception de sécurité MCP de la NSA comme socle.

Status

Élément	Référence	Date	Notes
Papier VIPER-MCP	arXiv:2605.21392 (cs.CR)	2026-05-20	Cadre d’audit statique + dynamique pour serveurs MCP
Périmètre du scan	Papier	2026-05-20	39 884 dépôts open source de serveurs MCP
Découvertes	Papier	2026-05-20	106 zero-days confirmés, 67 CVE attribuées à ce jour
Divulgation	Papier	2026-05-20	Divulgation responsable ; attribution CVE coordonnée
Exposition de l’écosystème	Adversa / Censys	2026-06-04	12 520 services MCP exposés sur Internet, ~40 % des serveurs distants non authentifiés

Le bon cadrage n’est pas « MCP est cassé » — c’est que les serveurs MCP sont des logiciels ordinaires avec des bugs d’injection ordinaires, déployés avec un privilège extraordinaire et souvent sans authentification. L’agent placé devant eux ne fait que rendre la source plus facile à atteindre pour un attaquant. Balayez vos serveurs pour les CVE divulguées, supprimez les sinks, et placez authentification et isolation devant tout ce qui peut exécuter une commande.