En 2025, on parlait de secrets hardcodés. En 2026, le problème a muté : tool poisoning, conversation hijacking, supply chain compromise. MCP n'est pas 'LE' vecteur d'attaque de l'ère agentique — mais il cristallise toutes ses failles, parce qu'il donne aux agents un accès réel aux systèmes.
En avril 2025, GitGuardian publiait un premier signal d’alarme : 5,2% des serveurs MCP contenaient des secrets hardcodés1. Six mois plus tard, Astrix Security enfonçait le clou : 53% utilisent des credentials statiques non sécurisés2.
Mais début 2026, ces chiffres ne racontent plus qu’une partie de l’histoire. Les secrets en dur ? C’était le symptôme visible d’un problème plus profond. Aujourd’hui, la surface d’attaque s’est élargie : tool poisoning, conversation hijacking, supply chain compromise, serveurs exposés sans authentification.
MCP n’est pas “LE” nouveau vecteur d’attaque — les failles de sécurité IA existent bien au-delà de ce protocole. Mais il cristallise les risques de l’ère agentique pour une raison simple : c’est le pont qui donne aux agents un accès réel à vos systèmes.
“MCP servers are fast becoming a backbone for AI agent development, but the way credentials are handled today is a ticking time bomb.” « Les serveurs MCP deviennent la colonne vertébrale du développement d’agents IA, mais la gestion actuelle des credentials est une bombe à retardement. » — Tal Skverer, Research Team Lead, Astrix Security
Et les credentials ne sont que le début.
MCP : le pont entre IA et système réel
MCP, c’est quoi ? Le Model Context Protocol est un protocole open-source créé par Anthropic. Il permet aux agents IA (Claude Desktop, Cursor, Windsurf, etc.) de se connecter de manière standardisée à des outils externes : fichiers locaux, APIs, bases de données, services cloud.
Avant MCP, un agent IA pouvait générer du texte, du code, des analyses. Avec MCP, il peut agir : lire vos fichiers, exécuter des commandes, appeler des APIs, modifier des bases de données.
C’est là que réside le changement fondamental — et le risque.
L’architecture MCP :
- MCP Hosts : l’application qui héberge l’IA (votre IDE, votre assistant)
- MCP Clients : la couche de communication
- MCP Servers : les “plugins” qui font le vrai travail — et qui ont besoin de credentials pour fonctionner
L’écosystème a explosé : plus de 20 000 implémentations sur GitHub, 16 000 serveurs indexés sur les registries comme mcp.so2. Des milliers de nouveaux serveurs chaque mois.
Le problème ? La sécurité n’a pas suivi.
Acte 1 : Les secrets (2025) — le signal d’alarme initial
GitGuardian tire la sonnette (avril 2025)
GitGuardian analyse les ~5 000 serveurs MCP référencés sur Smithery.ai. Résultat : 5,2% des dépôts contenaient au moins un secret hardcodé — légèrement plus que la moyenne GitHub (4,6%)1.
Les types de secrets les plus courants :
- Bearer tokens et X-Api-Key
- Clés d’API vers les fournisseurs LLM
- Credentials pour services distants
- Certificats TLS (y compris les clés privées)
- Tokens OAuth
Astrix Security quantifie le désastre (octobre 2025)
Six mois plus tard, l’analyse de 5 200 serveurs révèle l’ampleur du problème2 :
| Métrique | Chiffre |
|---|---|
| Serveurs nécessitant des credentials | 88% |
| Utilisant des secrets statiques/long-lived | 53% |
| API keys passées via variables d’environnement | 79% |
| Adoption d’OAuth (méthode sécurisée) | 8,5% |
Traduction : la majorité des serveurs MCP stockent des secrets en clair, sur la machine du développeur, avec des permissions trop larges et aucune rotation.
Le pattern “el clasico” :
- “J’ai besoin que mon agent accède à [service X]”
- Je crée un serveur MCP en 30 minutes
- Je mets ma clé API dans une variable d’environnement
- Ça marche → je passe à autre chose
- Six mois plus tard, ce “POC” est utilisé quotidiennement
C’est devenu la nouvelle classe de secret sprawl la plus dangereuse — chaque serveur MCP multiplie les credentials à gérer, souvent sans que personne ne s’en rende compte.
Acte 2 : L’escalade (fin 2025-2026) — au-delà des secrets
Les secrets hardcodés étaient le problème visible. Mais la surface d’attaque s’est considérablement élargie.
Les nouveaux vecteurs d’attaque
| Vecteur | Description | Gravité | Incidents documentés |
|---|---|---|---|
| Tool Poisoning | Serveur malveillant injecte des instructions via descriptions d’outils | Très haute | Exfiltration de repos GitHub privés, historique WhatsApp |
| Conversation Hijacking | Serveurs compromis manipulent les réponses LLM, exfiltrent des données en silence | Haute | Via MCP sampling (Anthropic/Claude) |
| Exposition réseau | Serveurs exposés sans auth (0.0.0.0, pas de HTTPS) | Critique | Bitsight TRACE : ~1000 serveurs vulnérables fin 2025 |
| Command Injection / RCE | Mauvaise sanitization → exécution arbitraire | Haute | CVE-2025-6514 (CVSS 9.6), path traversal Smithery.ai |
| Over-privileged tools | Agents avec accès excessif → compromission totale si faille | Très haute | Un serveur = accès filesystem + DB + APIs multiples |
| Supply chain / Typosquatting | Faux serveurs/packages dans les registries | Croissante | Typosquatting sur libs populaires |
Décortiquons les plus critiques.
Tool Poisoning
C’est la nouveauté qui fait mal. Un serveur MCP peut modifier sa propre définition après installation.
Le scénario “Rug Pull” :
- Jour 1 : vous installez un serveur MCP qui semble légitime
- Jour 7 : le serveur modifie silencieusement ses instructions
- Jour 8 : vos clés API, vos fichiers sensibles, votre historique de conversation sont exfiltrés
L’agent IA fait confiance aux descriptions des outils. Si ces descriptions contiennent des instructions malveillantes cachées, l’agent les exécute — lecture de fichiers sensibles, exfiltration de données, modification de configurations.
Insight : Le tool poisoning transforme des outils légitimes en chevaux de Troie. Pas de signature malware à détecter : c’est juste du texte dans une description que l’IA interprète comme une instruction.
Conversation Hijacking : le vol silencieux
Via le mécanisme de sampling de MCP (utilisé notamment par Claude), un serveur compromis peut :
- Intercepter les conversations en cours
- Modifier les réponses du LLM à la volée
- Exfiltrer des données sensibles mentionnées dans le contexte
L’utilisateur ne voit rien. L’agent continue de fonctionner “normalement”. Tout va bien. (Non.)
Exposition réseau : la porte grande ouverte
Bitsight TRACE a identifié environ 1 000 serveurs MCP exposés publiquement fin 2025, sans authentification, souvent sur 0.0.0.03.
Cas documenté : L’inspecteur MCP (outil de debug) tournait avec les privilèges utilisateur, sans authentification, exposé sur le réseau local. Résultat potentiel : accès au système de fichiers complet, aux clés API, aux variables d’environnement. Un outil de debug transformé en shell distant.
Supply Chain : le registre empoisonné
Les registries comme Smithery.ai ou mcp.so n’imposent aucun audit de sécurité. Publier un serveur MCP malveillant est trivial.
Le typosquatting classique s’applique : mcp-github vs mcp-githuh, slack-mcp vs slakc-mcp. Un développeur pressé installe le mauvais package, et c’est la compromission. Les mêmes bonnes pratiques de sécurité npm s’appliquent ici — vérification des auteurs, audit des dépendances, versioning strict.
Acte 3 : Les incidents réels
La théorie, c’est bien. Mais ces attaques sont-elles exploitables en conditions réelles ? Oui.
CVE-2025-6514 : le RCE critique
JFrog Security découvre une vulnérabilité critique (CVSS 9.6) dans mcp-remote — plus de 437 000 téléchargements4.
Impact : Exécution de commandes arbitraires quand un client MCP se connecte à un serveur non fiable.
Le package était référencé dans les guides d’intégration de Cloudflare, Hugging Face, Auth0. Chaque installation non patchée = une backdoor dans la supply chain.
La fuite Fly.io : 3 000 apps compromises
Un exploit a permis de récupérer le fichier ~/.docker/config.json d’un builder, incluant un token Fly.io donnant accès à plus de 3 000 applications — la plupart étant des serveurs MCP hébergés.
Résultat :
- Exécution de commandes dans les conteneurs MCP
- Interception du trafic entrant des clients
- Récupération des clés API transitant par ces serveurs
Un serveur MCP compromis devient un point de collecte pour tous les secrets de ses utilisateurs.
L’incident Supabase/Cursor : l’injection qui a fait mal
Mi-2025. L’agent Cursor de Supabase, configuré avec un accès service-role (privilégié), traitait des tickets support contenant des entrées utilisateur.
Des attaquants ont injecté des instructions SQL dans ces tickets. L’agent les a exécutées, exfiltrant des tokens d’intégration — directement dans un thread de support public.
Trois facteurs mortels combinés :
- Accès privilégié
- Entrées non validées
- Canal de communication externe
À retenir : Un agent IA avec des permissions larges + des données non fiables = une vulnérabilité garantie. Ce n’est pas un bug, c’est un défaut de conception.
Pourquoi ça ne s’améliore pas
Adoption > Maturité sécurité
L’écosystème MCP grandit plus vite que les bonnes pratiques ne se diffusent. Des milliers de nouveaux serveurs apparaissent chaque mois, créés par des développeurs qui veulent un résultat rapide.
La spécification MCP recommande des bonnes pratiques — OAuth 2.1 + PKCE, consentement explicite, human-in-the-loop. Mais “SHOULD” n’est pas “MUST”. Et personne ne vérifie.
Le syndrome “c’est juste local”
Beaucoup considèrent leurs serveurs MCP “locaux” comme non exposés. C’est faux :
- Les fichiers de config sont synchronisés (dotfiles, cloud sync)
- Les machines de dev sont rarement isolées
- Un malware ou une extension malveillante peut lire ces fichiers
- Les backups non chiffrés conservent ces secrets
Absence de gatekeeping
Les registries n’imposent aucun audit. Publier un serveur malveillant est trivial. Contrairement à npm ou PyPI qui ont (difficilement) mis en place des contrôles, l’écosystème MCP est encore le Far West.
Sécuriser MCP : comment ne pas finir dans le prochain rapport
Évolutions positives (mais lentes)
- Spécification officielle renforcée : OAuth 2.1 + PKCE recommandé, consentement explicite, sandboxing
- Nouveaux outils : MCP Secret Wrapper (Astrix, open-source), sandboxes runtime (Anthropic beta), proxies sécurisés
- Adoption enterprise : zero-trust pour MCP, allowlists stricts (ex. Agentforce de Salesforce), audit trails
Certains parlent déjà de “MCP comme nouveau OWASP LLM Top 10” — une reconnaissance que le problème est structurel et mérite un traitement systématique.
Checklist de survie (pour dormir la nuit)
1. Vault ou rien
Jamais de secrets en dur. Utilisez un gestionnaire :
- HashiCorp Vault, Doppler, AWS Secrets Manager
- MCP Secret Wrapper (Astrix, open-source)
Les secrets sont récupérés au runtime, jamais stockés sur disque.
2. OAuth plutôt que clés statiques
Quand c’est possible : OAuth 2.1 + PKCE, tokens à durée limitée, scopes restreints. Seulement 8,5% des serveurs l’utilisent. Félicitations, vous êtes probablement dans les 91,5% restants.
3. Least privilege systématique
Chaque serveur = uniquement les permissions nécessaires. Pas d’accès admin “au cas où”.
4. Sandbox et conteneurisation
- Conteneurs Docker avec capabilities réduites
- Transport
stdioplutôt que SSE exposé - Pas d’accès au filesystem hôte sauf nécessité absolue
- Outils comme MCPJail pour isolation renforcée
5. Allowlist strict
Ne faites confiance qu’aux serveurs que vous contrôlez ou venant de sources vérifiées. Avant d’installer :
- Lisez le code source
- Vérifiez l’auteur et l’historique
- En cas de doute, n’installez pas
6. Human-in-the-loop forcé
Désactivez l’auto-approval. La spécification dit “SHOULD always be a human in the loop” — traitez-le comme un “MUST”.
7. Monitoring continu
Surveillez : connexions inhabituelles, volumes anormaux, modifications des définitions d’outils, accès non prévus.
Soyons honnêtes
Ces problèmes ne sont pas nouveaux. Le secret sprawl existait avant MCP. Les supply chain attacks aussi. Le tool poisoning, c’est du prompt injection avec un autre nom.
Et sur 20 000+ serveurs MCP, on compte une poignée d’incidents documentés. Pas une hécatombe.
Alors pourquoi s’en préoccuper ?
Parce que MCP change l’échelle. Avant, une clé API dans un .env, c’était un risque isolé. Maintenant, c’est un serveur MCP qui parle à votre filesystem, votre base de données, vos APIs — et qui peut être manipulé par du texte dans une description d’outil.
Le problème n’est pas que MCP soit intrinsèquement dangereux. C’est qu’il amplifie les erreurs qu’on faisait déjà — et qu’il les met en production plus vite qu’on ne les corrige.
53% de serveurs avec des secrets statiques, c’est un fait. ~1000 serveurs exposés sans auth, c’est un fait. Des CVE critiques déjà exploitées, c’est un fait.
Est-ce alarmant ? Ça dépend de ce que vous branchez dessus.
MCP est en train de devenir l’USB-C des agents IA : un connecteur universel, pratique, et qui marche partout. Mais comme tout connecteur universel, il ne pose pas de questions sur ce qu’il transporte.
Standard ≠ sécurisé. C’est à vous de mettre les garde-fous.
Vous vous êtes endormi ? TL;DR
- Les secrets hardcodés étaient le symptôme visible — le problème est plus large : tool poisoning, hijacking, supply chain, exposition réseau
- 53% des serveurs MCP utilisent des credentials statiques non sécurisés, ~1000 sont exposés publiquement sans auth
- Des incidents réels ont déjà été documentés — ce n’est pas théorique
- MCP n’est pas “LE” vecteur d’attaque de l’ère agentique, mais il cristallise ses failles parce qu’il donne aux agents un accès réel aux systèmes
- L’adoption explose plus vite que la maturité sécurité — l’écosystème reste chaotique
- Les solutions existent mais demandent un effort délibéré : vault, OAuth, sandbox, allowlist, human-in-the-loop
Notes
-
GitGuardian, “A Look Into the Secrets of MCP”, avril 2025. Analyse de 3 829 dépôts GitHub. ↩ ↩2
-
Astrix Security, “State of MCP Server Security 2025”, octobre 2025. Analyse de 5 200+ serveurs MCP. ↩ ↩2 ↩3
-
Bitsight TRACE, “Exposed MCP Servers Reveal New AI Vulnerabilities”, décembre 2025. ↩
-
JFrog Security Research, CVE-2025-6514. Détails sur Authzed Timeline. ↩
