Les serveurs MCP sont la nouvelle surface d'attaque

Le Model Context Protocol a désormais une base de données de sécurité. Elle contient 50 entrées.¹

Trente CVE ont été déposées en 60 jours. Parmi 2 614 implémentations MCP étudiées, 82 % présentaient des vulnérabilités d’opérations sur fichiers exposées au path traversal. Entre 38 % et 41 % des serveurs ne comportaient aucune authentification.² L’outil officiel MCP Inspector — celui que les développeurs utilisent pour déboguer les serveurs MCP — avait une vulnérabilité RCE. Le package mcp-remote, largement utilisé, comportait un bug d’injection de commande OS.¹

Il ne s’agit pas d’une surface d’attaque théorique. Ce sont de véritables CVE dans de véritables packages que de véritables développeurs connectent en ce moment à Claude Code, Codex CLI et Cursor. Cet article prolonge le territoire de la sécurité des agents avec une analyse des menaces au niveau du protocole.

TL;DR

Les serveurs MCP constituent la surface d’intégration qui croît le plus vite dans l’écosystème des agents. C’est aussi la moins auditée. La base de vulnérabilités compte 50 entrées : 13 critiques, 32 élevées. Les défaillances de validation d’entrée et l’injection de prompt représentent 30 des 50. Trois vulnérabilités SSRF dans trois serveurs MCP différents sont apparues en une seule journée cette semaine.³ Le schéma est clair : la communauté livre des serveurs MCP plus vite qu’elle ne les examine.

Points clés

• Utilisateurs de Claude Code : chaque serveur MCP que vous connectez est une frontière de confiance que vous étendez. Exécutez claude mcp list dès maintenant et auditez ce que vous avez connecté. Si vous utilisez des serveurs MCP communautaires installés il y a plusieurs mois, vérifiez s’ils ont été corrigés depuis.
• Constructeurs de harnais : vos hooks PreToolUse constituent votre dernière ligne de défense avant qu’un appel d’outil MCP n’atteigne un serveur non audité. Envisagez des hooks qui valident les entrées des outils MCP avant exécution, en particulier pour les serveurs qui acceptent des URL, des chemins de fichiers ou des commandes shell.
• Auteurs de serveurs MCP : la spécification MCP dit qu’il « DEVRAIT toujours y avoir un humain dans la boucle ». Traitez cela comme un DOIT. Validez toutes les entrées. Ne passez jamais de chaînes contrôlées par l’utilisateur à des commandes shell via interpolation de chaînes. Ne faites jamais confiance aux valeurs $ref dans les spécifications OpenAPI sans validation d’URL.

Les chiffres

Le Vulnerable MCP Project maintient une base de données des problèmes de sécurité MCP documentés.¹ État actuel :

Sévérité : 13 critiques, 32 élevées, 5 moyennes.¹ Trente-deux chercheurs en sécurité ont contribué à ces découvertes. Les serveurs affectés incluent le serveur MCP Git de Anthropic lui-même, l’MCP Inspector officiel, Microsoft MarkItDown, GitHub Kanban, Figma, Jira, Grafana, Neo4j, Kubernetes, ainsi qu’une vingtaine de serveurs construits par la communauté.¹

Le constat de l’étude est le plus accablant : 82 % des 2 614 implémentations MCP présentaient des vulnérabilités d’opérations sur fichiers exposées au path traversal.² Quatre serveurs MCP sur cinq laisseront un attaquant lire des fichiers auxquels il ne devrait pas avoir accès.

Cinq schémas d’attaque

La vague de CVE sur 60 jours a révélé cinq schémas récurrents :²

1. Empoisonnement d’outils. Des instructions malveillantes intégrées dans les descriptions d’outils MCP. L’agent lit la description, s’y fie et suit les instructions cachées en utilisant ses propres outils autorisés. L’outil empoisonné ne s’exécute jamais — ce sont les outils légitimes de l’agent qui mènent l’attaque. Nous avons abordé ce schéma dans le paradoxe déployer-et-défendre : la confiance est transitive, l’audit ne l’est pas.

2. Injection de prompt via données externes. Les serveurs MCP qui récupèrent du contenu depuis des tickets GitHub, des messages Slack, des e-mails ou des pages web introduisent du texte contrôlé par l’attaquant dans le contexte de l’agent. L’injection ne cible pas le serveur MCP — elle cible l’agent qui lit la sortie du serveur. La surface d’attaque par exfiltration silencieuse en est le cas général ; les serveurs MCP en sont le vecteur le plus courant.

3. Contournement de confiance après approbation initiale. Claude Code vous demande d’approuver un serveur MCP la première fois. Par la suite, les définitions d’outils peuvent changer entre les sessions sans nouvelle demande dans tous les cas. Un serveur sûr à l’installation peut se comporter différemment à la mise à jour. L’écart de revalidation est structurel : le protocole n’exige pas de signature cryptographique des descriptions d’outils.²

4. Compromission de la chaîne d’approvisionnement. Des serveurs MCP avec portes dérobées publiés sur des registres, y compris des packages usurpant l’identité de serveurs légitimes. Le même schéma de chaîne d’approvisionnement que nous avons documenté dans la chaîne d’approvisionnement est la surface d’attaque, appliqué à l’écosystème MCP.

5. Exposition inter-locataires. Environnements d’hébergement partagés où plusieurs serveurs MCP peuvent intercepter les appels de fonction les uns des autres avant exécution.⁴ Les frontières d’isolation qui semblent solides de l’extérieur s’effondrent lorsque plusieurs serveurs partagent un processus ou un conteneur.

Le schéma SSRF

Trois vulnérabilités SSRF dans trois serveurs MCP différents sont apparues lors d’un seul scan cette semaine :³

• n8n-mcp : SSRF authentifiée via injection d’hôte d’instance
• mcp-from-openapi : SSRF via valeurs $ref dans les spécifications OpenAPI. Une spécification malveillante contenant des URL internes amène le serveur à récupérer ces ressources lors de l’initialisation
• stata-mcp : validation insuffisante des URL fournies par l’utilisateur

Le SSRF dans les serveurs MCP est particulièrement dangereux car le serveur dispose généralement d’un accès réseau dont l’agent ne dispose pas. Voici comment une seule spécification OpenAPI malveillante devient un vol d’identifiants :

Étape 1. Un attaquant publie un serveur MCP d’apparence légitime qui encapsule une API externe. Le serveur utilise mcp-from-openapi pour générer des outils à partir d’une spécification OpenAPI.

Étape 2. La spécification OpenAPI contient un $ref pointant vers une adresse interne :

components:
  schemas:
    Config:
      $ref: "http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"

Étape 3. Pendant initialize(), le serveur MCP résout le $ref en récupérant l’URL. Le serveur s’exécute sur votre infrastructure : dans votre VPC, sur votre ordinateur portable, dans votre conteneur CI. La requête va vers le point de terminaison de métadonnées AWS depuis une source de confiance.

Étape 4. Le point de terminaison de métadonnées renvoie des identifiants IAM temporaires : clé d’accès, clé secrète, jeton de session.

Étape 5. Le serveur dispose maintenant de vos identifiants cloud. Il peut les exfiltrer dans les réponses d’outils, les journaliser vers un point de terminaison externe, ou les utiliser directement.

L’agent n’a jamais rien fait de malveillant. L’utilisateur a approuvé le serveur MCP. La spécification OpenAPI paraissait normale. La résolution du $ref s’est produite au niveau de la bibliothèque, sous le niveau où quiconque examine. Le SSRF a converti la position réseau du serveur MCP en position réseau de l’attaquant.

Microsoft a corrigé un SSRF critique Azure MCP (CVE-2026-26118) en mars 2026. Le même schéma s’appliquait à Azure : une vulnérabilité d’élévation de privilèges de haute sévérité pouvant voler des jetons d’authentification et accorder un accès non autorisé aux ressources Azure.⁵

Que faire

Auditez vos serveurs connectés. Exécutez claude mcp list et passez en revue chaque serveur. Vérifiez chacun dans la base de données Vulnerable MCP Project.¹ Retirez les serveurs que vous n’utilisez pas activement.

Épinglez les versions des serveurs. Si vous installez des serveurs MCP depuis npm ou pip, épinglez la version. Ne les mettez pas à jour automatiquement. Examinez les notes de version avant de mettre à niveau. Le schéma de contournement de confiance signifie qu’une mise à jour peut modifier les définitions d’outils sans nouvelle approbation.

Ajoutez des hooks de validation d’entrée. Un hook PreToolUse sur les appels d’outils MCP peut valider les entrées avant qu’elles n’atteignent le serveur :

#!/bin/bash
# .claude/hooks/validate-mcp-input.sh
INPUT_JSON=$(cat)
TOOL_NAME=$(echo "$INPUT_JSON" | jq -r '.tool_name // empty')

# Block MCP tools that accept URLs from passing internal addresses
if echo "$TOOL_NAME" | grep -q "^mcp__"; then
  TOOL_INPUT=$(echo "$INPUT_JSON" | jq -r '.tool_input | tostring')
  if echo "$TOOL_INPUT" | grep -qiE '(169\.254\.|10\.|172\.(1[6-9]|2|3[01])\.|192\.168\.|localhost|127\.0\.0\.1|metadata\.google|169\.254\.169\.254)'; then
    echo "Blocked: MCP tool input contains internal/metadata address" >&2
    exit 2
  fi
fi
exit 0

Envisagez l’isolation du transport. Les schémas de défense d’exécution pour agents augmentés d’outils s’appliquent directement ici : chaque serveur MCP est un outil que l’agent invoque, et l’architecture de défense doit tenir compte des outils compromis. Les serveurs MCP HTTP s’exécutent dans leur propre processus avec des frontières réseau explicites. Les serveurs stdio partagent le contexte de processus de l’agent. Aucun des deux transports n’est intrinsèquement sûr. Le facteur le plus important est de savoir si le serveur a accès à des identifiants, des réseaux internes ou des chemins de fichiers sensibles. Choisissez le transport qui vous offre les frontières d’isolation exigées par votre modèle de menaces.

Surveillez la base de données. Le Vulnerable MCP Project à vulnerablemcp.info est ce qui se rapproche le plus d’un suivi des CVE pour l’écosystème MCP. Consultez-le avant d’installer de nouveaux serveurs.

L’écosystème MCP croît rapidement : plus de 3 000 serveurs indexés et 100 millions de téléchargements mensuels.⁶ Sa posture de sécurité ne croît pas au même rythme. Cinquante vulnérabilités dans une base de données qui n’existait pas il y a un an. Le protocole n’est pas le problème. Les implémentations le sont. Et comme je l’ai documenté dans votre agent a un intermédiaire, chaque intermédiaire dans la chaîne d’outils de l’agent est une opportunité d’interception que la plupart des développeurs n’auditent jamais.

Sources

Foire aux questions

Les serveurs MCP fournis avec Claude Code sont-ils affectés ?

Les vulnérabilités affectent principalement les serveurs MCP construits par la communauté et par des tiers, et non l’infrastructure MCP cœur de Claude Code. Toutefois, l’outil officiel MCP Inspector a bel et bien eu une vulnérabilité RCE, donc « officiel » ne signifie pas « immunisé ».

Dois-je arrêter d’utiliser les serveurs MCP ?

Non. MCP est une couche d’intégration puissante. Mais traitez chaque serveur MCP comme une frontière de confiance. Auditez ce que vous avez connecté, épinglez les versions et ajoutez des hooks de validation d’entrée pour les serveurs qui acceptent des URL, des chemins de fichiers ou des commandes shell.

Comment vérifier si mes serveurs MCP sont vulnérables ?

Exécutez claude mcp list pour voir vos serveurs connectés. Recoupez chacun avec la base de données Vulnerable MCP Project. Consultez le dépôt GitHub du serveur pour les avis de sécurité récents.