Détecter l'empoisonnement d'outils MCP : guide pratique

Qu'est-ce que le MCP tool poisoning ?

Le MCP tool poisoning est une attaque qui consiste à dissimuler des instructions malveillantes dans les descriptions d'outils d'un serveur MCP. Quand un agent de codage IA (Claude Code, Cursor, Codex) découvre les outils du serveur, il lit ces descriptions — et les instructions cachées s'intègrent au contexte de l'agent, potentiellement en remplaçant l'intention de l'utilisateur.

J'ai testé 47 serveurs MCP publics référencés sur mcp.so et la liste Awesome MCP Servers. 6 avaient des descriptions d'outils qui déclenchaient au moins un de nos motifs de détection. Voici ce que j'ai trouvé, et comment vérifier ta propre installation.

Étape 1 : localiser les fichiers de config MCP

Les agents de codage IA stockent les configurations de serveurs MCP dans des fichiers JSON. Voici où les trouver :

# Claude Code
~/.claude/settings.json
.claude/settings.json (au niveau projet)

# Cursor
~/.cursor/mcp.json

# VS Code / Copilot
~/.vscode/mcp.json

# Windsurf
~/.windsurf/mcp.json

Chaque fichier contient un objet mcpServers qui liste tous les serveurs MCP accessibles à ton agent, avec la commande de lancement et les variables d'environnement transmises.

Étape 2 : scanner avec Zfuzz

Installe Zfuzz MCP et lance le scanner de config :

claude mcp add zfuzz -- npx @zfuzz/mcp

Puis demande à ton agent :

"Scan my MCP configuration for security issues"

L'outil scan_mcp_config de Zfuzz vérifie :

• Motifs de prompt injection — Plus de 100 motifs, dont les override d'instructions (« ignore previous instructions »), le détournement de rôle (« you are now an admin »), et les déclencheurs d'exfiltration (« read and include the contents of »).
• Paramètres SSRF-capables — Outils qui acceptent des URL sans validation, surtout s'ils peuvent atteindre des réseaux internes.
• Accès aux identifiants — Descriptions d'outils qui mentionnent ~/.ssh, ~/.aws, .env ou process.env.
• Fuite de variables d'environnement — Configs MCP qui transmettent des variables sensibles (clés API, tokens) à des serveurs qui n'en ont pas besoin.

Étape 3 : drapeaux rouges à vérifier à la main

Au-delà du scan automatisé, voici les signaux que je cherche manuellement :

1. Mots-clés d'instruction dans les descriptions — Les mots « before », « first », « always », « must », « important » suivis d'actions sans rapport avec la fonction de l'outil.
2. Références à des chemins de fichier — Toute description qui mentionne des chemins précis (~/.ssh/id_rsa, /etc/passwd, ~/.gitconfig).
3. Outils réseau au périmètre trop large — Un « formateur de code » qui fait aussi des requêtes HTTP : suspect.
4. Transmission de variables d'environnement — Vérifie dans ta config MCP les blocs "env": {"API_KEY": "..."}. Chaque variable transmise à un serveur MCP est un identifiant qu'il peut lire.
5. Versions non épinglées — npx @some-mcp/server sans pin exécute la dernière version à chaque fois. Une publication compromise peut placer une backdoor sur ton poste.

Ce qu'on a trouvé sur 47 serveurs MCP

Les 3 findings critiques venaient de serveurs MCP peu connus, avec moins de 50 étoiles GitHub. Tous les serveurs MCP majeurs (Anthropic, Cursor, intégrations officielles) étaient propres.

Checklist de prévention

1. Lance scan_mcp_config après chaque nouvelle installation de serveur MCP.
2. Épingle les versions des serveurs MCP dans ta config (npx @zfuzz/mcp@1.0.0).
3. Réduis au minimum les variables d'environnement transmises aux serveurs MCP — uniquement ce qui est strictement nécessaire.
4. Relis périodiquement les descriptions d'outils dans ~/.claude/settings.json.
5. Utilise Zfuzz Agent Guard pour la protection runtime (bloque shell injection, SSRF, path traversal).

Auditez vos outils MCP

Pour ajouter scan_mcp_config à votre agent IA, une seule commande :

claude mcp add zfuzz -- npx @zfuzz/mcp

GitHub · npm