01Cadrage et inventaire
Tout commence par la définition de l'objet du test : transport (stdio, Streamable HTTP ou la voie HTTP+SSE dépréciée), révision du protocole et les trois parties que sont le serveur, le client/hôte et la passerelle. Seule la révision détermine quelles classes d'attaque existent réellement – le détournement de session via l'en-tête Mcp-Session-Id, par exemple, n'existe plus dans la révision 2026-07-28, qui introduit en revanche les state handles et la validation en-tête/corps. Nous cataloguons chaque serveur, chaque outil avec sa définition complète, chaque identifiant et chaque système cible accessible par ce biais, et nous fixons par écrit au préalable les identités de test et les portées utilisées, car tools/list peut varier selon l'autorisation présentée. Les outils de test font eux aussi partie du cadrage : le MCP Inspector – l'outil de test officiel du projet – a lui-même fait l'objet d'une vulnérabilité critique avec CVE-2025-49596, corrigée seulement à partir de la version 0.14.1 ; sa version doit donc être suivie et indiquée dans le rapport.
02Identité et autorisations (MCP07, MCP02)
Nous testons ici par rapport à des exigences normatives et non à des préférences : un appel d'outil sans jeton ou avec un jeton invalide doit se terminer par un 401 assorti d'un en-tête WWW-Authenticate correct, et la chaîne de découverte doit être présente et correctement liée. Une distinction s'impose : les Protected Resource Metadata selon la RFC 9728 sont obligatoires pour les serveurs MCP, tandis que pour le serveur d'autorisation la RFC 8414 ou OpenID Connect Discovery 1.0 suffit au choix – qui ne contrôle que la RFC 8414 produit un faux constat sur les serveurs OIDC. Pour les URL OAuth, la spécification exige HTTPS en dehors des adresses de loopback. Le cas de test central est la vérification de l'audience, car la spécification interdit explicitement le token passthrough – un serveur ne doit pas accepter de jetons qui n'ont pas été émis pour lui. Dans les architectures de type proxy s'ajoute le scénario du confused deputy : page de consentement dédiée par client, comparaison exacte de chaîne de la redirect_uri sans caractères génériques, paramètre state généré cryptographiquement et à usage unique. Nous vérifions en complément la minimisation des portées : portées génériques ou fourre-tout, privilèges groupés et serveurs qui font confiance au claim de portée contenu dans le jeton sans autoriser eux-mêmes.
03Définitions d'outils : poisoning, shadowing, rug pull (MCP03)
Les descriptions d'outils, la documentation des paramètres et les schémas JSON constituent un canal d'instructions que le modèle lit comme faisant autorité et que l'humain, en règle générale, ne voit jamais intégralement dans l'interface. Nous établissons d'abord une base de référence : chaque définition issue de tools/list, resources/list et prompts/list est hachée champ par champ et sert de référence pour les comparaisons ultérieures. Suivent trois contrôles – la confrontation entre le texte visible dans le client et la description réellement transmise au modèle, le test de rug pull contrôlé en environnement de test (si une définition déjà validée change, l'hôte doit demander un nouveau consentement ou signaler la modification) et le test de shadowing avec deux serveurs connectés en parallèle proposant des outils de même nom ou fonctionnellement redondants. La classe est démontrée en pratique : avec CVE-2025-54136 dans Cursor, des modifications de configurations MCP déjà validées prenaient effet sans nouveau consentement.
04Injection de prompt indirecte via les sorties d'outils (MCP06)
La surface d'attaque ne se limite pas à la description : le côté retour en fait aussi partie. La spécification oblige explicitement les serveurs à assainir les sorties d'outils (MUST) et recommande aux clients de valider les résultats d'outils avant de les transmettre au modèle (SHOULD) – l'exigence plus faible côté client doit être reflétée dans la formulation du constat. Nous inventorions d'abord tous les canaux par lesquels des contenus tiers entrent dans le contexte – réponses d'outils, pages et documents récupérés, contenus de dépôts, tickets, boîtes aux lettres, mémoire persistée – et introduisons dans chaque canal un marqueur inoffensif et clairement traçable afin d'observer si l'agent le traite comme une instruction ou comme une donnée. Une question architecturale centrale est ainsi examinée : existe-t-il une séparation de provenance entre instruction et données, ou les deux aboutissent-ils dans la même fenêtre de contexte ? Si un agent réunit simultanément l'accès à des données sensibles, le traitement de contenus non fiables et la possibilité de communiquer vers l'extérieur – la lethal trifecta selon Simon Willison –, le constat est déjà justifiable sur le plan architectural, même sans démonstration individuelle réussie.
05Transport, exécution et chaîne d'approvisionnement (MCP05, MCP04, MCP09)
Au niveau du transport s'appliquent des exigences strictes : les serveurs doivent valider l'en-tête Origin des connexions entrantes, et les instances exécutées localement devraient écouter sur 127.0.0.1 plutôt que sur 0.0.0.0 – sinon, la simple visite d'un site web suffit à dialoguer avec un serveur local par DNS rebinding. Nous vérifions la validation côté serveur par rapport au schéma déclaré, le traitement des URL dans le chemin de découverte OAuth (plages privées et link-local, chaînes de redirection, DNS rebinding comme scénario TOCTOU) ainsi que le cloisonnement et le contrôle des flux sortants lors de l'exécution des outils ; la seule démonstration qu'une entrée parvient sans contrôle jusqu'à un interpréteur constitue déjà le constat. Du côté de la chaîne d'approvisionnement, nous rapprochons l'entrée de registre, le dépôt et le mainteneur, et nous vérifions l'épinglage de version, les signatures et les portes de validation des mises à jour – des mentions telles que « official » ou « verified » ne constituent pas une preuve de confiance, comme l'a montré CVE-2025-6514 dans le paquet très répandu mcp-remote (versions 0.0.5 à 0.1.15 concernées, corrigé en 0.1.16). S'y ajoute la recherche de serveurs fantômes via des scans de dépôts et de points de terminaison, des scans réseau répétés avec rapport différentiel ainsi que l'exploitation des données de la passerelle, car c'est là que l'on mesure quels serveurs un agent contacte réellement – et pas seulement lesquels figurent dans la configuration.
06Télémétrie, administration de la preuve et rapport (MCP08)
La question la plus difficile vient à la fin : peut-on reconstituer a posteriori quel agent a appelé quel outil, à quel moment, avec quels paramètres et pour le compte de quelle identité ? Nous exécutons pour cela une séquence d'actions définie et inoffensive – connexion, listage des outils, plusieurs appels, un appel refusé – puis nous tentons de reconstituer précisément cette séquence à partir des seuls journaux ; un constat négatif net est ici un résultat à part entière, car il rend tous les autres constats indémontrables en exploitation. Dans le rapport, nous distinguons deux catégories de preuve : les constats de configuration et d'architecture sont démontrables de manière déterministe, les constats fondés sur le comportement ne le sont pas – pour ces derniers, nous indiquons le nombre de répétitions, le taux de réussite ainsi que le modèle, le client et la version. Chaque constat est en outre rattaché au niveau auquel il se situe (protocole et transport, autorisation, définition d'outil, client/hôte, niveau agent), car la contre-mesure et le responsable diffèrent selon le niveau.
