Un serveur MCP sur trois est une passerelle SSRF vers vos métadonnées cloud

De quoi s’agit-il ?

Le Model Context Protocol (MCP) est le tissu conjonctif entre les agents IA et le monde extérieur : systèmes de fichiers, bases de données, API, services cloud. Deux travaux de mesure indépendants publiés en 2026 suggèrent désormais qu’une large part de l’écosystème MCP public embarque la même classe de vulnérabilité web qui mine les logiciels serveur depuis dix ans — le server-side request forgery (SSRF).

Trend AI Security a scanné 9 695 serveurs MCP sur GitHub, Glama, Lobehub et PulseMCP ; les résultats ont été rapportés le 7 juillet 2026. L’étude relève 5 832 serveurs présentant des problèmes de sécurité et 2 259 confirmés exploitables au-delà de simples absences d’authentification, avec 4 982 problèmes distincts recensés, dont 422 failles SSRF, 880 accès arbitraire à des fichiers, 476 injections de commandes et 185 cas d’injection de prompt. Par ailleurs, l’analyse de BlueRock, en janvier 2026, portant sur plus de 7 000 serveurs de son MCP Trust Registry, rapporte que plus de 36,7 % présentaient une exposition potentielle au SSRF (« récupération réseau non restreinte »). Corpus différents, même message : le SSRF n’est pas un cas marginal dans le monde MCP, c’est la norme.

Comment ça marche

Un serveur MCP est plus qu’un simple gestionnaire de requêtes. Quand un agent appelle l’un de ses outils, le serveur agit : il récupère des URL, lit des fichiers, exécute du code. Le SSRF apparaît dès qu’un outil accepte un argument URL ou hôte et le récupère sans validation.

L’exemple travaillé par BlueRock est le serveur MCP MarkItDown de Microsoft — un convertisseur document-vers-Markdown, environ 85 000 étoiles sur GitHub. Son outil convert_to_markdown accepte une URI arbitraire et la récupère sans restriction de schéma ni d’hôte. Sur une instance AWS EC2 utilisant encore le service de métadonnées historique IMDSv1, un agent (ou un attaquant capable d’orienter l’agent) peut pointer cet outil vers l’endpoint de métadonnées cloud :

convert_to_markdown("http://169.254.169.254/latest/meta-data/iam/security-credentials/")
# → renvoie le nom du rôle IAM attaché
# ajouter le nom du rôle à ce chemin → clé d'accès, clé secrète, jeton de session

Ces identifiants renvoyés peuvent ensuite être rejoués contre l’API cloud, offrant un accès au compte limité au rôle de l’instance — et, selon ce rôle, un chemin d’escalade de privilèges dans le compte. Le point crucial est architectural : cette exposition vit au niveau de la couche d’exécution des outils, sous la frontière de requête qu’inspectent les passerelles MCP. Une passerelle peut laisser passer une requête d’apparence valide tout en laissant le serveur exfiltrer des identifiants pendant l’exécution.

Pourquoi c’est important

Le constat le plus inconfortable porte sur les signaux de confiance. Le scan de Trend AI Security ne relève aucune corrélation significative entre la popularité d’un serveur et sa sécurité : les serveurs très populaires (50 étoiles et plus) portent souvent le plus grand risque parce que leur rayon d’impact est plus large, l’activité de commits ne prédit pas la sûreté, et les badges « vérifié » des annuaires ne changent presque rien — les serveurs vérifiés affichent un nombre moyen de vulnérabilités quasi identique aux non vérifiés. Les heuristiques vers lesquelles les équipes se tournent instinctivement pour choisir une dépendance — étoiles, activité, coche de vérification — n’ont ici presque aucune valeur comme indicateurs de sécurité.

Comme les serveurs MCP s’exécutent souvent avec les privilèges de l’utilisateur ou de la charge de travail qui les a lancés, une faille SSRF ou d’accès aux fichiers reste rarement confinée à l’outil. C’est un pivot vers tout ce que cette identité peut atteindre : métadonnées cloud, services internes, secrets. Quand le même serveur populaire est déployé dans de nombreuses organisations, une seule faille devient systémique — ce que BlueRock et les auteurs du scan qualifient de sévérité pondérée par la portée.

Défenses

Traitez chaque serveur MCP tiers comme du code non fiable s’exécutant à l’intérieur de votre périmètre de confiance, et contraignez ce que ses outils peuvent récupérer :

• Allowlist en sortie. Restreignez les récupérations des outils à une allowlist explicite de schémas/hôtes (par exemple, uniquement https:// vers des domaines approuvés) plutôt qu’une blocklist.
• Bloquez les cibles internes. Refusez les plages RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), la boucle locale, le lien-local, et l’IP de métadonnées cloud 169.254.169.254.
• Neutralisez le DNS rebinding. Résolvez le nom d’hôte et vérifiez l’IP résolue contre la denylist avant de vous connecter, pas seulement la chaîne de caractères.
• Supprimez IMDSv1. Imposez IMDSv2 (jeton de session requis) sur chaque instance ; il existe précisément pour émousser le vol de métadonnées par SSRF. Associez-le à des rôles d’instance à moindre privilège.
• Préférez stdio, en local. Exécutez les serveurs MCP en stdio lié à localhost plutôt que de les exposer en HTTP ; fixez des délais d’expiration, des plafonds de taille de corps, et retirez les en-têtes Authorization/Cookie transmis.
• Surveillez l’exécution, pas seulement les requêtes. Observez ce que les outils font réellement à l’exécution ; l’inspection au seul niveau passerelle manque la couche où cette classe de bug se déclenche.
• Abandonnez les heuristiques de confiance. Ne traitez pas les étoiles, la vélocité des commits ou un badge de vérification comme un signal de sécurité. Auditez le code ou scannez le serveur avant de le connecter.

Statut

Élément	Détail
SSRF MarkItDown MCP	Signalé à Microsoft et AWS en novembre 2025 ; les deux ont répondu que des contournements sont disponibles. Divulgation publique janvier 2026. Aucun CVE attribué.
Prévalence SSRF dans l’écosystème	BlueRock : > 36,7 % de 7 000+ serveurs (janv. 2026). Trend AI Security : 422 SSRF parmi 4 982 problèmes sur 9 695 serveurs (7 juil. 2026).
Mitigation	IMDSv2, allowlist en sortie et surveillance à la couche d’exécution disponibles dès aujourd’hui ; l’écart, c’est l’adoption.

Sources : l’étude « Stars Don’t Save You » de Trend AI Security sur l’écosystème MCP (rapportée le 7 juillet 2026) et la divulgation « MCP fURI » de BlueRock sur le serveur MarkItDown de Microsoft (janvier 2026).