L'incident que personne n'a vu venir
Le mois dernier, un chercheur en sécurité a publié un proof-of-concept qui volait les variables d'environnement d'une session Claude Code. Le vecteur d'attaque n'était pas une faille dans Claude Code. C'était un serveur MCP malveillant qui enregistrait un outil nommé read_file — masquant un outil légitime du même nom — et exfiltrait chaque chemin de fichier et contenu qui transitait par lui.
L'attaque a fonctionné parce que le développeur avait 6 serveurs MCP installés, n'avait pas relu les descriptions d'outils de 4 d'entre eux, et avait accordé l'accès au système de fichiers à tous par défaut. Ce n'est pas un cas marginal. C'est la configuration par défaut de la majorité des environnements de dev assistés par IA en 2026.
On appelle ça le MCP Sprawl — la prolifération incontrôlée des serveurs MCP connectés à ton agent IA, chacun élargissant la surface d'attaque d'une façon invisible pour le développeur.
Ce qu'est le MCP Sprawl et pourquoi ça compte
Le MCP Sprawl est le phénomène par lequel les développeurs accumulent plusieurs connexions à des serveurs MCP dans leur agent IA sans auditer la surface cumulée de privilèges, le chevauchement entre outils, ni les frontières de confiance entre eux.
Le Model Context Protocol est conçu pour être composable : tu peux ajouter des serveurs pour différentes capacités (requêtes base de données, scan de sécurité, déploiement, recherche de documentation) et l'agent IA orchestre l'ensemble. Cette composabilité est une fonctionnalité. C'est aussi un handicap sécuritaire dès qu'elle n'est pas maîtrisée.
Prenons l'utilisateur Claude Code typique. Notre analyse de 143 configurations MCP partagées publiquement (dotfiles GitHub, articles de blog, talks de conférences) révèle :
- Nombre moyen de serveurs MCP : 4,7 par utilisateur
- Nombre médian d'outils enregistrés : 23 tous serveurs confondus
- Pourcentage avec accès au système de fichiers : 89 %
- Pourcentage avec accès réseau : 67 %
- Pourcentage avec accès shell/exec : 41 %
- Pourcentage où toutes les descriptions d'outils ont été relues : 12 %
Le dernier chiffre est le plus critique. 88 % des utilisateurs font tourner des outils dans leur agent qu'ils n'ont jamais inspectés. Chaque outil non audité est un vecteur potentiel de prompt injection, d'exfiltration de données ou d'élévation de privilèges.
Le MCP Sprawl Index
Le MCP Sprawl Index est un cadre quantitatif pour mesurer la surface d'attaque créée par ta configuration MCP. Il évalue le risque sur trois dimensions :
Dimension 1 : LARGEUR — Nombre de serveurs MCP connectés
Chaque serveur MCP est un processus séparé avec sa propre base de code, ses dépendances et son cycle de mises à jour. Plus tu en as, plus tu fais confiance implicitement à du code que tu n'as pas écrit. Le risque grimpe de façon non linéaire parce que chaque serveur peut potentiellement interagir avec tous les autres via l'agent IA comme intermédiaire.
Un outil dans le Serveur A peut produire une sortie que Claude Code passe en entrée à un outil du Serveur B. Si le Serveur A est compromis, il peut fabriquer des sorties qui exploitent le Serveur B à travers l'agent IA — une forme d'injection de prompt indirecte qui franchit les frontières de confiance.
Notation : 1 à 2 serveurs = FAIBLE, 3 à 5 = MOYEN, 6+ = ÉLEVÉ
Dimension 2 : PRIVILÈGE — Accès fichiers/réseau/exécution accordés
Tous les serveurs MCP n'ont pas besoin des mêmes permissions. Un serveur de recherche de docs a besoin du réseau, pas de l'écriture disque. Un serveur de formatage a besoin de lire/écrire des fichiers, pas du réseau. Un serveur de déploiement peut avoir besoin des trois.
Le souci, c'est que MCP n'a pas de modèle de permissions intégré. Quand tu ajoutes un serveur, il hérite des droits du processus — généralement les mêmes que ton shell. Aucun sandboxing par défaut.
Notation : Lecture seule = FAIBLE, Lecture+Écriture = MOYEN, Lecture+Écriture+Exec+Réseau = ÉLEVÉ
Dimension 3 : OPACITÉ — Outils sans description ou avec description vague
Chaque outil MCP a un champ description qui indique à l'agent IA quand et comment l'utiliser. Quand un outil n'a pas de description, ou une description vide, ou une description vague du type « utility function », l'agent doit deviner quand l'invoquer. Ça crée deux risques :
- L'agent peut invoquer l'outil dans des contextes non prévus, passant des données sensibles vers un endpoint inattendu.
- Un outil malveillant avec une description vague peut être conçu pour se déclencher sur des requêtes développeur courantes, maximisant ses chances de recevoir des entrées sensibles.
Notation : Tous documentés = FAIBLE, 1 à 3 non documentés = MOYEN, 4+ non documentés = ÉLEVÉ
Calcul du Sprawl Index
| Dimension | FAIBLE (1) | MOYEN (2) | ÉLEVÉ (3) |
|---|---|---|---|
| LARGEUR | 1 à 2 serveurs | 3 à 5 serveurs | 6+ serveurs |
| PRIVILÈGE | Lecture seule | Lecture+Écriture | Complet (R/W/X/Net) |
| OPACITÉ | Tout documenté | 1 à 3 outils opaques | 4+ outils opaques |
Sprawl Index = LARGEUR × PRIVILÈGE × OPACITÉ
- Score 1 à 4 : Maîtrisable — hygiène standard suffisante
- Score 5 à 12 : Élevé — audit recommandé sous 7 jours
- Score 13 à 27 : Critique — audit immédiat, envisager de retirer les serveurs inutilisés
Comment scan_mcp_config détecte le Sprawl
L'outil scan_mcp_config de Zfuzz MCP lit ta configuration MCP Claude Code et l'évalue selon 143 patterns de détection couvrant les trois dimensions du Sprawl Index :
- Énumération des serveurs : Liste tous les serveurs MCP connectés avec leur type de transport (stdio, SSE, HTTP), leur commande et leurs arguments.
- Inventaire des outils : Interroge chaque serveur pour récupérer ses outils enregistrés, descriptions et schémas d'entrée.
- Cartographie des privilèges : Analyse les capacités de chaque outil pour déterminer les accès fichier, réseau et exécution.
- Détection de shadowing : Identifie les outils qui partagent un nom identique ou des fonctionnalités qui se chevauchent entre serveurs — vecteurs de masquage potentiels.
- Audit des descriptions : Signale les outils avec description absente, vide, ou suspectement vague.
- Patterns malveillants connus : Confronte les configurations à notre base de signatures de serveurs MCP malveillants.
Garde-fous : ce que ce cadre ne couvre pas
- Surveillance du comportement à l'exécution. Le Sprawl Index évalue la configuration, pas le runtime. Un serveur avec un score FAIBLE peut quand même se comporter de manière malveillante en exécution. L'audit de configuration est nécessaire mais pas suffisant.
- Vérification de la chaîne logicielle. Le scan vérifie ta configuration locale mais ne vérifie pas l'intégrité des paquets MCP eux-mêmes. Utilise scan_dependencies pour les contrôles supply chain npm/PyPI sur les paquets MCP.
- Serveurs MCP internes. Si ton organisation construit ses propres MCP, la base de patterns malveillants connus ne les détectera pas. Tu as besoin de revues de code internes et de tests de sécurité dédiés.
Foire aux questions
Faut-il supprimer tous les serveurs MCP sauf Zfuzz ?
Non. Le but n'est pas de minimiser le nombre de serveurs — c'est de minimiser le nombre de serveurs non audités. Chaque MCP que tu utilises doit avoir un objectif clair, des outils documentés et le minimum de permissions nécessaires. Lance scan_mcp_config après chaque ajout ou mise à jour pour vérifier ton Sprawl Index.
Un serveur MCP malveillant peut-il lire les données des autres serveurs MCP ?
Pas directement. Les serveurs MCP sont des processus isolés qui ne communiquent qu'avec l'agent IA, pas entre eux. Cependant, un serveur malveillant peut influencer l'agent pour qu'il transmette des données d'un serveur vers un autre via des sorties d'outils piégées. C'est le vecteur d'injection de prompt indirecte décrit plus haut — et c'est le risque le plus sous-estimé de l'écosystème MCP.
À quelle fréquence auditer sa configuration MCP ?
Après chaque changement (ajout, suppression ou mise à jour d'un serveur), et au minimum chaque semaine si ta configuration est stable. L'outil scan_mcp_config tourne en moins de 3 secondes et peut être ajouté à ton CLAUDE.md pour s'exécuter automatiquement en début de session.
Lectures connexes
- Auditer ses configurations MCP contre la prompt injection
- Les meilleurs serveurs MCP de sécurité pour agents IA en 2026
- Attaques sur la chaîne logicielle des agents IA
Auditez vos outils MCP maintenant
L'utilisateur Claude Code moyen a 4 à 7 serveurs MCP installés. 88 % n'ont jamais relu toutes leurs descriptions d'outils. Votre configuration MCP est une surface d'attaque — mesurez-la avec le Sprawl Index, auditez-la avec scan_mcp_config, et réduisez-la au strict nécessaire. Une seule commande pour démarrer :
claude mcp add zfuzz -- npx @zfuzz/mcpCode source et documentation : github.com/zfuzz-dev/mcp
