Un chercheur divulgue la même faille MCP chez Google, JPMorgan et deux gouvernements

Le chercheur indépendant en sécurité Syed Anas Mohiuddin a révélé dans une mise à jour de recherche d’octobre 2026 que la même erreur de falsification de requête côté serveur dans les serveurs Model Context Protocol a été confirmée et corrigée par les équipes de sécurité de cinq organisations indépendantes : Google, JPMorgan Chase, Weaviate, la direction interministérielle du numérique de la France, et le gouvernement de la ville de Tangerang en Indonésie.

La mise à jour, intitulée « Protocol Pivoting, four months later », teste une prédiction que Mohiuddin a formulée en mai 2026 : si la faiblesse était structurelle plutôt qu’une simple implémentation négligente, le même bug apparaîtrait dans des serveurs écrits par des équipes ne partageant ni code, ni secteur, ni pays, ni propriétaire. Il indique que chacune des cinq organisations a confirmé le problème via sa propre équipe de sécurité, et que le fournisseur de sécurité Rapid7 a publié séparément une CVE pour un bug différent mais connexe. La mise à jour recense cinq organisations qui ont corrigé la même SSRF, deux ont publié des CVE, et cinq constats dans les serveurs MCP fédéraux américains restent ouverts.

Mohiuddin décrit deux modes de défaillance à l’origine du schéma. Le premier est la falsification de requête côté serveur : un serveur MCP construit une requête sortante à partir d’une URL, d’un chemin ou d’un point de terminaison fourni par un agent sans vérifier où il se résout, de sorte que l’agent décide effectivement avec quoi l’identité réseau du serveur communique. Le second est la manipulation non sécurisée des données en amont, notamment l’écriture des réponses complètes d’API en amont dans les journaux centralisés sans aucune rédaction, ce qui suffit à déclencher des erreurs ordinaires. Il attribue les deux à une même hypothèse : que les données traversant la frontière MCP sont considérées comme fiables parce qu’elles proviennent de l’intérieur du système, hypothèse qu’il estime ne pas tenir dans une chaîne de traitement agentique.

CVE‑2026‑14540 dans la boîte à outils MCP de Google

Selon l’entrée de la base de données d’avis GitHub pour la CVE‑2026‑14540, publiée par le National Vulnerability Database, une vulnérabilité SSRF existe dans les composants source HTTP génériques et les outils du mcp-toolbox de Google, versions 0.3.0 à 1.4.0. Comme le client HTTP ne disposait d’aucune politique de redirection restrictive et ne validait jamais les adresses IP de destination, un paramètre de chemin spécialement conçu pouvait rediriger les requêtes sortantes de la boîte à outils vers des points de terminaison internes ou externes arbitraires. L’avis classe la faille comme de gravité élevée avec un score CVSS de 8,0 ; il a été publié le 31 juillet 2026 et mis à jour le 8 août 2026. Mohiuddin indique que la CVE a été réservée le 3 juillet 2026 et que le registre le cite comme découvreur.

Google a intégré la correction, pull request #3448 dans le dépôt googleapis/mcp-toolbox, le 18 juin 2026, et elle a été livrée dans mcp-toolbox v1.5.0. La pull request implémente un SSRFGuard pour empêcher les attaques de rebinding DNS pendant l’intervalle entre la vérification d’adresse et la connexion, ajoute les propriétés configurables allowPrivateNetworks, allowedIpRanges et customBlockedIpRanges, valide le BaseURL configuré lors de l’initialisation plutôt qu’à la première requête, et avertit explicitement du risque d’interception (man‑in‑the‑middle) lorsque la vérification SSL est désactivée. La PR cite Mohiuddin comme le rapporteur, et Mohiuddin décrit la remédiation de Google comme une implémentation de référence d’un véritable garde‑SSR​F.

Quatre autres cas confirmés

Mohiuddin rapporte que le dépôt open‑source jpmorgan-payments/ai de JPMorgan Chase comprend un serveur MCP de recherche de documentation dont l’outil read_documentation applique une liste blanche de domaines avant la récupération, tandis que son outil frère related() récupère une URL fournie par l’appelant côté serveur sans aucune restriction. Il indique que le composant a été dérivé d’un projet AWS dont l’original ne résolvait jamais l’URL de l’appelant, que l’équipe de divulgation responsable de la banque a confirmé la validité de la découverte, et qu’une correction a été déployée. Il figure nommément sur la page publique de reconnaissance des divulgations responsables de JPMorgan Chase et évalue la découverte comme de gravité moyenne, en notant qu’aucune information d’identification n’accompagne la requête falsifiée.

Weaviate, indique‑t‑il, a intégré une pull request limitant les paramètres apiEndpoint, region et location du module Google aux hôtes d’API Google, et le cite nommément dans son entrée publique du Hall of Fame de la sécurité datée du 25 août 2026.

Le projet datagouv/datagouv-mcp a intégré pull request #126, “feat: harden SSRF on external APIs”, le 4 septembre 2026, et la pull request commence en créditant Mohiuddin comme rapporteur. Selon la PR, un champ machinedocumentationurl fourni par tout producteur enregistré sur data.gouv.fr était récupéré côté serveur et pouvait pointer vers des adresses de bouclage, de réseau privé ou de métadonnées cloud, le rebinding DNS pouvant changer la cible entre la vérification et la connexion et une redirection 302 pouvant aboutir à un hôte interne. La correction valide l’IP de destination au moment de la connexion, revérifie chaque saut de redirection et refuse les proxys. Mohiuddin identifie le projet comme le serveur MCP officiel de la plateforme nationale française de données ouvertes, maintenu par la DINUM, la direction interministérielle du numérique.

Un Avis de sécurité GitHub publié le 3 septembre 2026 par les mainteneurs d’INFOKOM-KI/Wazuh-MCP-Server, classé Élevé, indique que l’outil blueteamvérificationwebshell dont la protection SSRF annoncée ne rejetait que les adresses IP littérales et ne résolvait jamais les noms d’hôte, de sorte que tout nom DNS pointant vers une adresse privée, de bouclage ou link‑local, y compris les métadonnées d’instance cloud, contournait cette protection. L’avis note que la garantie documentée de l’outil, “SSRF Protection: Private/reserved IPs in the URL host are rejected,” ne s’appliquait pas aux URL basées sur des noms d’hôte. La faille a été corrigée dans le commit 2bbfe12, et l’avis crédite Mohiuddin comme rapporteur. Mohiuddin indique l’avoir signalée le 2 septembre 2026, que les mainteneurs ont répondu depuis une adresse tangerangkota.go.id, et que le projet est maintenu par le gouvernement de la ville de Tangerang en Indonésie.

Rapid7’s entrée de la base de données de vulnérabilités pour CVE-2026-97228 enregistre une injection de requête GraphQL dans Rapid7 Bulk Export MCP versions 0.2.5 à 0.6.1, dans laquelle un argument d’outil d’export id MCP non validé est interpolé directement dans une requête GraphQL. Rapid7 lui attribue un score de 2,7, Faible, sur l’échelle CVSS 3.1, a publié l’enregistrement le 25 septembre 2026, et indique que les requêtes injectées s’exécutent dans le périmètre de l’API de l’opérateur et ne peuvent pas franchir la frontière d’un locataire ; la version 0.6.2 corrige le problème en passant l’exportid comme variable paramétrée. Mohiuddin indique que Rapid7 l’a crédité en tant que découvreur.

Au‑delà de ces cas, Mohiuddin indique qu’à la date de la mise à jour, 16 avis de sécurité GitHub publiés par les propres mainteneurs des projets le créditent comme rapporteur, couvrant le SSRF ainsi que l’injection de commandes, les lacunes d’authentification, le détournement de session, les fuites d’identifiants et les contournements de correctifs antérieurs, et qu’il a vu des correctifs fusionnés dans des projets tels que github-mcp-server, mongodb-mcp-server et salesforce-mcp-server.

Constatations gouvernementales non résolues

Mohiuddin indique avoir déposé cinq constatations sous forme d’avis de sécurité GitHub privés le 2 septembre 2026, couvrant des serveurs MCP relevant des Technology Transformation Services de la GSA : un serveur de réclamations d’avantages du Department of Veterans Affairs, un serveur CMS Blue Button, un serveur regulations.gov, un serveur USASpending et un serveur CDC PLACES. Il précise que les cinq restent en phase de triage, ne sont pas corrigés et ne sont pas présentés comme des résultats confirmés.

Dans le cas du VA, qu’il décrit uniquement au niveau de la classe, le serveur consigne le corps complet de l’erreur de l’API des avantages en amont au niveau ERROR sans aucune rédaction ; ces corps peuvent contenir le nom d’un vétéran, son numéro de sécurité sociale, sa date de naissance et son adresse, et il indique que des échecs de validation courants suffisent à déclencher cette journalisation en fonctionnement normal. Il retient les détails au niveau du code jusqu’à ce que les serveurs soient corrigés.

Il indique également que le 1er septembre 2026 il a informé le JPCERT que le jgrants-mcp-server de l’Agence numérique du Japon ne disposait d’aucune authentification, et que le 7 septembre 2026 il a ouvert une pull request publique exigeant un consentement explicite pour lier le serveur à autre chose que le bouclage et limitant la taille d’écriture des pièces jointes. La pull request n’a pas été fusionnée, et il ne la présente pas comme un résultat confirmé.

Pivotement de protocole et la conférence MCPCon

Mohiuddin définit le pivotement de protocole comme une attaque en plusieurs étapes dans laquelle un adversaire pénètre via un protocole, exploite les hypothèses de confiance que les protocoles placent les uns dans les autres, puis passe à des capacités disponibles uniquement via un autre protocole. Son exemple concret insère un texte ressemblant à une instruction de tâche A2A dans la sortie d’un outil MCP ; un agent orchestrateur le transmet à un sous‑agent comme une délégation normale, et le sous‑agent, faisant confiance à son orchestrateur, l’exécute.

Le prépublication formelle, “Protocol Pivoting: Cross-Protocol Attack Escalation in Agentic AI Systems,” a été publié sur Zenodo le 24 mai 2026. Il présente trois scénarios : escalade de privilèges MCP‑vers‑A2A via délégation de confiance implicite, injection de capacités A2A‑vers‑MCP via usurpation d’agent malveillant, et chaînes d’injection d’invite inter‑protocoles. Il analyse également pourquoi les défenses existantes échouent contre cette classe et propose un cadre de sécurité inter‑protocoles unifié avec un modèle formel de frontière de confiance et trois mesures d’atténuation indépendantes du protocole.

Les travaux de mai ont débuté avec le playwright-mcp de Microsoft, dont l’outil browser_navigate acceptait n’importe quelle URL fournie par l’agent sans protection SSRF, permettant ainsi de diriger un agent vers le service de métadonnées d’instance AWS à l’adresse 169.254.169.254 et d’en extraire les identifiants. Mohiuddin indique avoir signalé cela comme une issue publique sur GitHub, qu’aucun CVE n’existe et qu’aucune confirmation du fournisseur n’a été obtenue, et que la notation de gravité repose sur son propre jugement.

Mohiuddin soutient que l’analyse de composition logicielle et les scanners de dépendances passent à côté de cette classe parce que l’entrée dangereuse arrive via le transport sous forme d’argument d’outil décrit dans un manifeste d’outil que le scanner ne lit jamais, ce qui fait que le graphe d’appels s’arrête à la frontière du transport. Il indique avoir créé mcp-safeguard, un scanner open‑source qui teste les serveurs MCP à travers leur surface d’outil exposée sans nécessiter le code source, à la recherche de six catégories : SSRF, permissions excessives, surfaces d’injection d’invite, fuite d’informations, lacunes d’authentification et contournement du cycle de vie. Il précise également que les outils de correspondance de motifs, y compris le sien, manquent une grande partie de cette classe.

Mohiuddin indique qu’il présentera le modèle inter‑fournisseurs le 23 octobre 2026 lors du MCPCon North America à San Jose, incluant les constatations qui auront été corrigées d’ici là, et que les constatations fédérales resteront privées jusqu’à leur correction.