Une étude menée par OX Security a répertorié 15 465 serveurs MCP accessibles publiquement, dont 5 095 noms d’hôte uniques. L’analyse révèle l’absence totale de contrôle de qualité dans les places de marché MCP, ce qui crée une surface d’attaque largement sous‑estimée pour les organisations qui intègrent ces serveurs dans leurs flux d’IA.
Contexte du protocole MCP
Le Model Context Protocol (MCP) a été lancé en 2024 comme une interface standardisée pour relier modèles d’IA, agents et environnements de développement. Son ambition était de devenir le "USB‑C" de l’IA, facilitant l’interopérabilité entre outils. En pratique, le protocole a rapidement été adopté : des milliers de développeurs ont déployé des serveurs MCP, et les entreprises les ont intégrés à leurs pipelines d’automatisation. Cependant, le modèle de distribution repose sur des registres ouverts où tout contributeur peut publier un serveur sans validation préalable.
Analyse de la surface d’attaque
Le rapport montre que 0,45 % des serveurs utilisent des services de tunnel grand public, principalement ngrok‑free, ce qui indique que des instances tournent depuis des machines personnelles et des réseaux domestiques. Cette configuration expose les agents à des points d’entrée non protégés, car le trafic transite par des canaux qui ne sont pas soumis aux politiques Zero Trust habituelles. De plus, 2,3 % des domaines associés aux serveurs ne résolvent plus, et six d’entre eux sont expirés. Un acteur malveillant pourrait racheter ces domaines à 4–12 $ par an, récupérer l’identité du serveur et intercepter les requêtes des agents déjà configurés.
Risques de souveraineté des données
Environ 15,6 % des noms d’hôte résolvent vers des infrastructures situées hors des États‑Unis, dont 19 en Chine et 18 en Russie. Un agent qui se connecte à ces serveurs peut transmettre des données sensibles vers des juridictions non approuvées, contournant les règles de résidence des données et les contrôles d’accès granulaire mis en place pour le cloud public. Le manque de mécanismes d’authentification forte au niveau du registre empêche les équipes de sécurité de vérifier l’origine du serveur avant l’établissement de la connexion.
Recommandations pour les équipes de sécurité
Face à l’absence de vetting, les organisations doivent instaurer leurs propres processus de validation : vérifier le code source publié, comparer le binaire exécuté avec le dépôt, et appliquer des signatures de code. L’utilisation de listes blanches d’adresses IP ou de noms d’hôte approuvés permet de restreindre les connexions aux serveurs dont la localisation est connue et contrôlée. Enfin, il est recommandé de surveiller les résolutions DNS des serveurs MCP afin de détecter rapidement les changements de propriétaire ou les expirations de domaine.
