Comment MCP est devenu un angle mort de sécurité à grande échelle
Model Context Protocol (MCP) a été conçu pour résoudre un problème d’intégration : au lieu d’écrire des connecteurs personnalisés pour chaque outil qu’un agent IA pourrait nécessiter, les développeurs enregistrent des outils via un protocole standardisé et laissent le LLM décider lesquels invoquer. En avril 2026, MCP a atteint 97 millions d’installations et acquis le statut de standard de facto comme couche de connecteurs pour les agents IA d’entreprise — de GitHub Copilot Workspace aux pipelines internes de traitement de documents.
L’efficacité de conception du protocole est aussi sa vulnérabilité de sécurité. Quand un outil est enregistré dans un écosystème MCP, son nom, sa description et son schéma de paramètres sont chargés directement dans la fenêtre de contexte du LLM. Le modèle raisonne à partir de ces descriptions pour décider quels outils invoquer. Cela signifie que quiconque contrôle la description d’un outil contrôle une partie de l’espace d’instructions du modèle — et les descriptions d’outils ne sont ni validées, ni signées, ni isolées par défaut dans la plupart des implémentations clients MCP.
Le tool poisoning exploite précisément cette lacune. Un acteur malveillant peut intégrer des instructions cachées dans le champ de description d’un outil ou dans son schéma de paramètres. Ces instructions sont invisibles pour l’utilisateur qui examine les outils disponibles de l’agent, mais elles sont présentes dans la fenêtre de contexte du LLM et peuvent rediriger son comportement : exfiltrer des données vers un point d’accès non autorisé, contourner des contrôles d’accès, invoquer des outils supplémentaires non prévus par l’utilisateur, ou injecter de fausses informations dans les sorties.
Invariant Labs a formellement documenté cette classe d’attaque dans leur avis MCP Security Notification on Tool Poisoning Attacks. Elastic Security Labs a publié indépendamment une analyse des vecteurs d’attaque des outils MCP. Une comparaison systématique de sept clients MCP majeurs par des chercheurs académiques a révélé que la plupart ont des problèmes de sécurité significatifs, une validation statique insuffisante, et une visibilité limitée des paramètres — et la spécification MCP elle-même n’exige pas de validation côté client des métadonnées fournies par le serveur.
La surface d’attaque dépasse les descriptions d’outils
Les recherches initiales sur le tool poisoning se concentraient sur le champ description — le point d’injection le plus évident. Des travaux plus récents, dont le benchmark MCPTox (couvrant plus de 45 serveurs MCP réels dans 8 domaines d’application) et l’analyse de Palo Alto Networks Unit 42 sur les vecteurs d’attaque MCP via l’API Sampling, ont révélé que la surface d’attaque est substantiellement plus large.
Chaque élément du schéma d’outil qui entre dans la fenêtre de contexte du LLM est un vecteur d’injection potentiel : noms de paramètres, descriptions de paramètres, schémas de valeur de retour, charges utiles de réponse d’outil. L’API MCP Sampling — qui permet aux composants côté serveur de demander des complétions au LLM — crée un chemin d’attaque supplémentaire où un serveur MCP malveillant peut interagir directement avec le modèle sans passer par le flux d’invocation d’outils du client.
La classe d’attaque par empoisonnement de mémoire étend cela davantage. Si un agent IA maintient une mémoire persistante (comme le font typiquement les agents LangChain et LangGraph, et comme l’API Assistants d’OpenAI le supporte), un attaquant qui peut placer un seul appel d’outil empoisonné peut corrompre la mémoire — créant « des décisions constamment mauvaises, pour toujours » plutôt qu’une attaque ponctuelle. C’est l’équivalent MCP d’une Menace Persistante Avancée.
Des CVE réels confirment que cette classe de menace a déjà franchi la frontière de la recherche vers l’exploitation en production. CVE-2025-3248 (Langflow, CVSS 9.8) permet l’exécution de code à distance non authentifiée sur une plateforme de workflow IA agentique. CVE-2025-34291 (Langflow) chaîne une mauvaise configuration CORS avec des tokens de rafraîchissement SameSite=None pour permettre le vol d’identifiants cross-origin et l’exécution de code authentifié. CVE-2025-64496 (Open WebUI) permet à des serveurs de modèles malveillants d’exécuter du JavaScript arbitraire dans les navigateurs victimes via l’API Functions.
Publicité
Ce que les équipes sécurité d’entreprise doivent cartographier maintenant
1. Construire un registre complet des outils MCP avant de connecter des données de production
Le prérequis pour la sécurité MCP est de connaître les outils enregistrés dans le contexte de l’agent. Dans la pratique, les écosystèmes MCP croissent organiquement — les développeurs ajoutent des outils depuis des registres communautaires, des paquets npm, et des serveurs MCP tiers sans processus d’approbation formel. Les équipes sécurité doivent établir un registre des outils MCP : un inventaire documenté de chaque outil connecté à chaque agent de production, incluant la source du serveur MCP, la version utilisée, et qui a examiné la description et le schéma de paramètres avant le déploiement.
Ce registre sert deux objectifs. Premièrement, il permet l’analyse statique des descriptions d’outils avant qu’elles n’entrent en production — un examinateur humain ou automatisé peut inspecter les métadonnées d’outils pour des motifs d’instruction suspects. Deuxièmement, il crée un journal d’audit permettant la chasse aux menaces : si un outil compromis est découvert, vous pouvez immédiatement identifier quels agents sont affectés.
2. Appliquer la validation des entrées au niveau du client MCP, pas seulement au niveau du modèle
La plupart des discussions sur la sécurité MCP se concentrent sur le durcissement des prompts — écrire des prompts système qui instruisent le modèle d’ignorer les instructions contradictoires. Cette approche est incomplète car elle repose sur les propres défenses du modèle contre une classe d’attaque spécifiquement conçue pour les contourner. Le taux de réussite de 97 % des jailbreaks multi-tours illustre pourquoi les défenses au niveau du modèle seules sont insuffisantes.
Le contrôle plus robuste est la validation au niveau du client MCP : vérification de conformité du schéma (rejeter les réponses d’outils ne correspondant pas au schéma enregistré), détection de motifs de contenu (signaler les réponses contenant des instructions comme « ignore les instructions précédentes »), et limites de taille de réponse. Des bibliothèques implémentant cette couche commencent à émerger dans l’écosystème MCP ; pour les équipes construisant leurs propres clients MCP, ajouter ce middleware représente un effort d’ingénierie d’une à deux semaines.
3. Délimiter les permissions des agents à l’ensemble d’outils minimal viable
Chaque outil connecté à un agent IA de production élargit le rayon de souffle d’une attaque de tool poisoning réussie. Un agent ayant accès à un outil d’exécution shell, un outil d’envoi d’e-mails, un outil de requête de base de données, et un outil d’écriture de fichiers, combiné avec un outil de documentation en lecture seule empoisonné, peut être redirigé pour exécuter des commandes arbitraires, exfiltrer des données par e-mail, et persister des modifications — le tout via une seule description d’outil compromise.
Implémentez la délimitation des outils au déploiement : chaque configuration d’agent doit spécifier l’ensemble minimal d’outils requis pour sa fonction désignée, avec tous les autres outils explicitement exclus. Pour les agents déployés via des plateformes comme LangChain, LangGraph ou Microsoft Copilot Studio, les listes d’outils doivent être codées en dur dans la configuration de déploiement plutôt qu’assemblées dynamiquement au moment de l’exécution.
4. Traiter les serveurs MCP tiers comme des composants de chaîne d’approvisionnement non fiables
L’écosystème MCP a grandi rapidement, avec une communauté de serveurs MCP tiers disponibles comme paquets npm, paquets PyPI, images Docker et services API hébergés. Ces composants tiers sont des composants de chaîne d’approvisionnement — soumis aux mêmes risques que toute dépendance open source : compromission du mainteneur, typosquatting, piratage de paquet, et mises à jour malveillantes publiées via des tokens de publication volés.
Les équipes sécurité d’entreprise doivent appliquer le même processus de vérification des dépendances aux paquets de serveurs MCP que pour toute dépendance open source critique : vérifier la source du paquet et l’historique du mainteneur, épingler à des versions spécifiques plutôt que de flotter vers latest, examiner le code du serveur MCP pour les appels réseau sortants au-delà de la fonctionnalité d’outil déclarée, et s’abonner aux avis de sécurité pour chaque serveur MCP utilisé.
La leçon structurelle : une nouvelle frontière d’exécution
La communauté sécurité a passé des décennies à apprendre à traiter les entrées fournies par l’utilisateur comme non fiables. L’injection SQL, le XSS, l’injection de commandes et le path traversal sont tous des variations du même thème : un attaquant fournit une entrée interprétée comme code plutôt que comme données. Le tool poisoning MCP est la même catégorie de vulnérabilité appliquée à une nouvelle frontière d’exécution — la frontière entre le raisonnement du LLM et les outils qu’il peut invoquer.
La différence est l’échelle et l’invisibilité. Une charge utile d’injection SQL est visible dans les journaux HTTP. Une charge utile de tool poisoning est intégrée dans un champ de description d’outil, chargée silencieusement dans le contexte du LLM à l’initialisation de l’agent, et agit à travers le raisonnement propre du modèle plutôt qu’une requête réseau qui déclencherait une alerte. Les WAF standards, les règles de corrélation SIEM et les politiques DLP n’ont pas été conçus pour inspecter cette frontière.
L’Agence de cybersécurité de Singapour et CISA ont toutes deux émis des orientations en 2026 sur la sécurité des agents IA qui traitent explicitement de cette frontière d’exécution. Les équipes sécurité d’entreprise doivent traiter les métadonnées des outils MCP avec la même méfiance que les entrées de requêtes SQL : valider, nettoyer et surveiller.
Questions Fréquemment Posées
Qu’est-ce que le MCP tool poisoning et en quoi diffère-t-il d’une injection de prompt standard ?
Dans une injection de prompt standard, un attaquant intègre des instructions malveillantes dans du contenu traité par le modèle. Le tool poisoning MCP cible spécifiquement les métadonnées d’outils — le nom, la description et le schéma de paramètres des outils enregistrés dans un écosystème MCP. Comme les métadonnées d’outils sont chargées dans la fenêtre de contexte du LLM à l’initialisation de l’agent plutôt que pendant l’exécution des tâches, un outil empoisonné peut rediriger le comportement de l’agent sur toutes les tâches ultérieures, le rendant plus persistant qu’une injection de prompt ponctuelle.
Quelles vulnérabilités réelles démontrent que le MCP tool poisoning n’est pas seulement un risque théorique ?
CVE-2025-3248 (Langflow, CVSS 9.8) permet l’exécution de code à distance non authentifiée sur une plateforme de workflow IA agentique — démontrant que les attaquants ciblent activement l’infrastructure IA agentique à des scores CVSS de production. CVE-2025-64496 (Open WebUI) permet à des serveurs de modèles malveillants d’exécuter du JavaScript arbitraire dans les navigateurs victimes via l’API Functions adjacent à MCP. Le benchmark MCPTox, couvrant plus de 45 serveurs MCP réels, a confirmé que les attaques de tool poisoning réussissent dans toutes les implémentations testées en l’absence de validation côté client.
Comment les organisations se protègent-elles contre les attaques de chaîne d’approvisionnement MCP sur des paquets de serveurs tiers ?
Traiter les paquets de serveurs MCP comme des dépendances critiques de chaîne d’approvisionnement : épingler à des versions spécifiques publiées plutôt que de flotter vers latest, examiner le code source du paquet pour les appels réseau sortants non déclarés, vérifier l’historique du mainteneur et les anomalies de téléchargement, et s’abonner aux flux CVE et d’avis pour chaque serveur MCP en production. Pour les serveurs MCP fournissant un accès à des systèmes sensibles, préférer les implémentations auto-hébergées avec du code auditable aux services hébergés par des tiers.
Sources et lectures complémentaires
- MCP Security Notification: Tool Poisoning Attacks — Invariant Labs
- MCP Tools: Attack Vectors and Defense Recommendations — Elastic Security Labs
- New Prompt Injection Attack Vectors Through MCP Sampling — Palo Alto Networks Unit 42
- MCP Security Vulnerabilities: How to Prevent Prompt Injection and Tool Poisoning — Practical DevSecOps
- AI Agents Hacking in 2026: Defending the New Execution Boundary — Penligent
- Agentic AI: Cybersecurity Nightmare 2026 — JazzCyberShield
- OWASP Top 10 for LLM Applications: Prompt Injection & Supply Chain Risks — OWASP
