Un chercheur indépendant a démontré comment des failles de sécurité au sein du protocole MCP (Model Context Protocol) permettaient à des instructions génératives malveillantes de se propager d’un agent IA à un autre. Les serveurs MCP stockent les identifiants de chaque agent et que, par défaut, les agents font confiance à tout autre agent interne. Par conséquent, une instruction générative bien conçue et adressée au bon agent conduit à une falsification de requête côté serveur (SSRF), une vulnérabilité qui pousse un serveur web à effectuer des requêtes réseau non autorisées. Au cours des cinq derniers mois, Google, JP Morgan Chase, Weaviate, Rapid7, la Direction interministérielle du numérique en France et le gouvernement fédéral américain ont reconnu l’existence de vulnérabilités liées au protocole MCP. Le Model Context Protocol (MCP) est un cadre ouvert et open source lancé par Anthropic en novembre 2024 afin de normaliser la manière dont les systèmes d’intelligence artificielle (IA), tels que les grands modèles de langage (LLM), intègrent et partagent des données avec des outils, des systèmes et des sources de données externes. Le MCP fournit une interface normalisée pour la lecture de fichiers, l’exécution de fonctions et le traitement des invites contextuelles. Suite à son annonce, le protocole a été adopté par les principaux fournisseurs d'IA, notamment OpenAI et Google DeepMind.
En décembre 2025, Anthropic a fait don du MCP à l'Agentic AI Foundation, un fonds relevant de la Linux Foundation. Selon l'annonce, le MCP d'Anthropic se distingue comme un protocole permettant de gérer le contexte dans les interactions IA, permettant aux agents de maintenir leur état d'une session à l'autre et de collaborer avec des humains ou d'autres systèmes. Cela est particulièrement pertinent pour les applications d'entreprise, où la continuité est cruciale. La fondation vise à s'appuyer sur ces outils pour établir des références en matière de fiabilité et de sécurité des agents, répondant ainsi aux préoccupations concernant les comportements involontaires de l'IA autonome.
Malgré une telle annonce, en mars 2026, deux acteurs majeurs de l'écosystème IA ont ébranlé la confiance dans le Model Context Protocol (MCP) : Denis Yarats, directeur technique de Perplexity, a annoncé publiquement que son entreprise abandonnait le protocole en interne au profit des API REST classiques ; pendant ce temps, Cloudflare publiait une analyse technique cinglante démontrant pourquoi l'architecture MCP traditionnelle est fondamentalement inadaptée aux agents IA à grande échelle. Ces deux coups portés simultanément relancent un débat crucial : le MCP, présenté comme l'USB-C de l'intelligence artificielle (IA), était-il une promesse prématurée ?
Récemment, un chercheur indépendant a démontré comment des failles de sécurité au sein du protocole MCP permettaient à des instructions génératives malveillantes de se propager d’un agent IA à un autre. Au cours des cinq derniers mois, Google, JP Morgan Chase, Weaviate, Rapid7, la Direction interministérielle du numérique en France et le gouvernement fédéral américain ont reconnu l’existence de vulnérabilités liées au protocole MCP. Dans chaque cas, un attaquant pouvait amener un agent IA au sein d’un réseau d’entreprise à transmettre des instructions malveillantes à d’autres agents.
Ces attaques relèvent de la catégorie des « injections de prompts » : le texte malveillant n’est pas injecté dans un grand modèle de langage, mais dans un agent distinct, tel qu’un module de traduction ou d’analyse de données. Ces agents utilitaires ne disposent souvent d’aucun dispositif de sécurité, ou leurs filtres sont insuffisants. L’agent transmet l’instruction à l’agent suivant de la chaîne, et celui-ci l’exécute car il fait confiance à l’expéditeur.
Le Model Context Protocol (MCP) est une norme ouverte grâce à laquelle les applications et les agents d’IA échangent des tâches au sein d’un réseau. Le chercheur indépendant Syed Anas Mohiuddin a testé des agents chez Google, JP Morgan Chase, Weaviate, Rapid7, la Direction interministérielle du numérique en France et le gouvernement fédéral américain. Ses attaques de preuve de concept montrent que les serveurs MCP stockent les identifiants de chaque agent et que, par défaut, les agents font confiance à tout autre agent interne.
Par conséquent, une instruction générative bien conçue et adressée au bon agent conduit à une falsification de requête côté serveur (SSRF), une vulnérabilité qui pousse un serveur web à effectuer des requêtes réseau non autorisées. Cela est difficile à détecter car chaque protocole surveille sa propre « porte d’entrée », et personne ne surveille le « couloir » entre les deux. La vulnérabilité découverte par Mohiuddin chez Rapid7 s’est vu attribuer le numéro CVE-2026-97228 et un niveau de gravité de seulement 2,7 sur 10. Rapid7 l’a corrigée le mois dernier.
Le problème de Google était plus grave — 8 sur 10. Il était lié à la boîte à outils MCP pour les bases de données, googleapis/mcp-toolbox : lors de l’initialisation du client HTTP, celle-ci n’utilisait pas de politique CheckRedirect et ne validait pas les adresses IP cibles. Un paramètre de chemin spécialement conçu forçait la boîte à outils à suivre une redirection vers une adresse interne et à envoyer des requêtes au nom de l’attaquant. Le correctif de Google a ajouté une liste blanche de plages d’adresses IP et des listes noires : une URL de base non sécurisée est désormais rejetée au démarrage plutôt qu’à la première requête.
Mohiuddin a qualifié cela de « véritable protection contre les attaques SSRF » et a noté que la plupart des serveurs MCP n’avaient pas mis en place ce niveau de renforcement de la sécurité. Mohiuddin qualifie cette catégorie d’attaques de « protocol pivoting ». Il s’agit d’une attaque en plusieurs étapes au cours de laquelle un attaquant obtient un accès initial via un protocole, exploite les hypothèses de confiance entre les protocoles, puis étend ses capacités à des fonctionnalités disponibles uniquement via un autre protocole.
Par exemple, une application ou un serveur utilise le protocole MCP pour attribuer une tâche à un agent, et cet agent transmet des instructions malveillantes à un autre agent en utilisant une norme différente — le protocole Agent-to-Agent (A2A) de Google ou le protocole Agent Network Protocol, en plein essor. Lors de telles transitions, la confiance et l’autorisation sont souvent perdues. Markus Vervier, de X41 D-Sec, qui a également mené des recherches sur les attaques visant le protocole MCP, n’est pas de cet avis.
Le fait que le « protocol pivoting » ait fonctionné dans cinq organisations qui n’avaient rien en commun à part le MCP est remarquable. Ce protocole est nouveau mais déjà omniprésent — il s’est répandu plus vite qu’il n’a pu être suffisamment testé et renforcé. Dans la course à la construction d’architectures d’agents IA tentaculaires, les entreprises ont abandonné le « zero trust », un modèle de sécurité dans lequel le réseau est considéré comme infecté dès le départ et où chaque requête sensible entre les nœuds nécessite une autorisation.
Selon une analyse : « La leçon que je souhaite que les gens retiennent, c’est que tout ce qui est transmis par un LLM à votre outil doit être traité comme une entrée provenant d’un inconnu sur Internet, car dans un scénario d’injection de prompt, c’est exactement ce dont il s’agit. Les failles sous-jacentes sont des vieilles connaissances, comme l’injection et le SSRF, et les correctifs n’ont pas changé depuis 20 ans. Il faut rendre hommage au chercheur pour avoir donné un nom à ce phénomène, car c’est ce nom qui incite les défenseurs et les organismes de normalisation à réellement concevoir des solutions pour y faire face. »
Pourtant fin juillet 2026, le Model Context Protocol (MCP) a connu sa plus importante mise à jour depuis son lancement. Il convient notamment de noter que le cœur du protocole MCP est désormais sans état, ce qui signifie que les requêtes ne dépendent plus d’une session liée à une instance de serveur spécifique. Une nouvelle politique de dépréciation garantit également un délai d’au moins 12 mois entre la date à laquelle la dépréciation officielle d’une fonctionnalité est prononcée et celle à laquelle elle peut effectivement être supprimée — à l’exception, dans des cas très limités, des mises à jour de sécurité critiques.
Source : Rapport de Syed Anas Mohiuddin
Et vous ?
Pensez-vous que ce rapport est crédible ou pertinent ? Quel est votre avis sur le sujet ?Voir aussi :
Pourquoi ne peut-on pas simplement empêcher les IA malveillantes d'accéder à Internet ? Isoler physiquement l'IA pour l'éloigner des cibles du monde réel rend les tests plus sûrs, mais moins utiles Des millions d'agents IA menacés par une faille critique dans un paquet open source. « BadHost » a été découvert dans Starlette, un paquet téléchargé 325 millions de fois par semaine La Fondation Linux lance le projet "Protocole Agent2Agent" afin de permettre une communication sécurisée et intelligente entre les agents d'IA
Vous avez lu gratuitement 114 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.
