Les serveurs MCP sont la nouvelle surface d'attaque

Le Model Context Protocol dispose désormais d’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 analysées, 82 % présentaient des vulnérabilités d’opérations fichier sujettes au path traversal. Entre 38 % et 41 % des serveurs ne disposaient d’aucune authentification.² L’outil officiel MCP Inspector — celui que les développeurs utilisent pour déboguer les serveurs MCP — présentait une vulnérabilité RCE. Le package largement utilisé mcp-remote contenait un bug d’injection de commande OS.¹

Il ne s’agit pas d’une surface d’attaque théorique. Ce sont de vrais CVE dans de vrais packages que de vrais développeurs connectent à Claude Code, Codex CLI et Cursor en ce moment même.

TL;DR

Les serveurs MCP constituent la surface d’intégration à la croissance la plus rapide dans l’écosystème agent. C’est aussi la moins auditée. La base de données de vulnérabilités compte 50 entrées : 13 critiques, 32 élevées. Les défauts de validation des entrées et l’injection de prompt représentent 30 des 50 cas. Trois vulnérabilités SSRF dans trois serveurs MCP différents ont émergé en une seule journée cette semaine.³ Le constat est clair : la communauté déploie les serveurs MCP plus vite qu’elle ne les audite.

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 maintenant et auditez ce que vous avez connecté. Si vous utilisez des serveurs MCP communautaires installés il y a des mois, vérifiez s’ils ont été corrigés depuis.
• Développeurs de harness : vos hooks PreToolUse sont 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 stipule 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 l’interpolation de chaînes. Ne faites jamais confiance aux valeurs $ref dans les spécifications OpenAPI sans validation d’URL.

Les chiffres

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

Sévérité : 13 critiques, 32 élevées, 5 moyennes.¹ Trente-deux chercheurs en sécurité ont contribué leurs découvertes. Les serveurs affectés incluent le serveur Git MCP de Anthropic, l’outil officiel MCP Inspector, Microsoft MarkItDown, GitHub Kanban, Figma, Jira, Grafana, Neo4j, Kubernetes, et plus de 20 serveurs communautaires.¹

Le résultat de l’enquête est le plus accablant : 82 % des 2 614 implémentations MCP présentaient des vulnérabilités d’opérations fichier sujettes au path traversal.² Quatre serveurs MCP sur cinq permettent à un attaquant de 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’outil. Des instructions malveillantes intégrées dans les descriptions d’outils MCP. L’agent lit la description, lui fait confiance 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 couvert ce schéma dans le paradoxe déploiement-défense : la confiance est transitive, l’audit ne l’est pas.

2. Injection de prompt via des données externes. Les serveurs MCP qui récupèrent du contenu depuis des issues 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 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 de confirmation dans tous les cas — un serveur sûr au moment de l’installation peut se comporter différemment lors d’une mise à jour. Le défaut 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 piégés publiés dans des registres, y compris des packages qui usurpent 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-tenants. Des 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 ont émergé lors d’un seul scan cette semaine :³

• n8n-mcp : SSRF authentifié via injection de l’hôte d’instance
• mcp-from-openapi : SSRF via les valeurs $ref dans les spécifications OpenAPI — une spécification malveillante contenant des URL internes pousse 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 que l’agent n’a pas. Voici comment une seule spécification OpenAPI malveillante se transforme en 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. Lors de l’initialize(), le serveur MCP résout le $ref en récupérant l’URL. Le serveur s’exécute sur votre infrastructure — au sein de votre VPC, sur votre ordinateur portable, dans votre conteneur CI. La requête atteint 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 enregistrer vers un point de terminaison externe, ou les utiliser directement.

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

Microsoft a corrigé un SSRF critique dans Azure MCP (CVE-2026-26118) en mars 2026 — le même schéma appliqué à Azure : une vulnérabilité d’élévation de privilèges de haute sévérité capable de voler des jetons d’authentification et d’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 d’eux dans la base de données du projet Vulnerable MCP.¹ Supprimez les serveurs que vous n’utilisez pas activement.

Verrouillez les versions des serveurs. Si vous installez des serveurs MCP depuis npm ou pip, verrouillez la version. Ne mettez pas à jour automatiquement. Consultez les changelogs avant toute mise à 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 des entrées. 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 serveurs MCP HTTP s’exécutent dans leur propre processus avec des frontières réseau explicites. Les serveurs stdio partagent le contexte du processus de l’agent. Aucun des deux transports n’est intrinsèquement sûr — le facteur déterminant est de savoir si le serveur a accès aux identifiants, aux réseaux internes ou aux chemins de fichiers sensibles. Choisissez le transport qui offre les frontières d’isolation requises par votre modèle de menace.

Surveillez la base de données. Le projet Vulnerable MCP sur vulnerablemcp.info est ce qui se rapproche le plus d’un outil de suivi 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.⁶ La posture de sécurité ne suit pas le 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. Ce sont les implémentations.

Sources

Foire aux questions

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

Les vulnérabilités concernent principalement les serveurs MCP communautaires et tiers, et non l’infrastructure MCP centrale de Claude Code. Néanmoins, l’outil officiel MCP Inspector présentait une vulnérabilité RCE — « officiel » ne signifie donc pas « immunisé ».

Faut-il arrêter d’utiliser les serveurs MCP ?

Non. MCP est une couche d’intégration puissante. Toutefois, traitez chaque serveur MCP comme une frontière de confiance. Auditez ce que vous avez connecté, verrouillez les versions et ajoutez des hooks de validation des entrées 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 du projet Vulnerable MCP. Vérifiez le dépôt GitHub du serveur pour les avis de sécurité récents.