MCPwn n'est pas un accident isole. C'est le premier symptome visible d'un probleme structurel : le Model Context Protocol s'est invite dans des outils d'infrastructure critique sans que les equipes securite aient eu le temps d'en cartographier la surface d'attaque. Quand un protocole permet a un agent IA de modifier la configuration de votre serveur web frontal, le bypass d'authentification cesse d'etre une CVE parmi d'autres pour devenir une question de souverainete sur votre propre stack. Et la verite, c'est qu'on n'est pas pret.

Un protocole jeune dans des roles seniors

Le Model Context Protocol a ete publie en novembre 2024 par Anthropic comme un standard ouvert pour connecter les modeles d'IA a des sources de donnees et des outils. En dix-huit mois, il s'est diffuse dans des dizaines d'integrations : IDE, outils DevOps, plateformes de monitoring, et maintenant des interfaces de gestion d'infrastructure comme nginx-ui. Le rythme d'adoption est typique d'une technologie qui resout un vrai probleme. Le rythme de durcissement, lui, est en retard d'au moins une annee.

Sur nginx-ui, l'integration MCP exposait deux endpoints HTTP. L'un protege par authentification, l'autre filtre uniquement par whitelist d'IP. Et la whitelist par defaut, vide, etait interpretee comme "autoriser tout le monde". Cette erreur n'est pas une erreur de cryptographie sophistiquee. C'est une faute de configuration triviale, le genre d'erreur qu'on apprenait a eviter dans les annees 2010 sur les API REST classiques. Sauf qu'ici, l'endpoint vulnerable permet d'invoquer des actions privilegiees : ecriture et rechargement de configuration nginx. Autrement dit, prise de controle complete du serveur web frontal en deux requetes HTTP.

Le glissement subtil vers l'execution distante banalisee

Ce qui rend MCP dangereux n'est pas le protocole lui-meme. C'est ce qu'il transporte : des intentions executables. Quand vous exposez un endpoint MCP, vous n'exposez plus seulement des donnees, vous exposez des actions. Lecture, ecriture, execution de commandes, modification de configuration. Le modele mental hereditaire des developpeurs, qui distingue encore "endpoint en lecture" et "endpoint en ecriture", ne tient pas face a un protocole ou chaque outil expose peut representer une primitive d'attaque.

Et personne ne fait l'inventaire. Combien d'organisations ont une cartographie a jour de tous les serveurs MCP exposes dans leur SI ? Combien savent quelles actions chaque serveur MCP peut declencher ? Combien ont mis en place une revue de code systematique des outils MCP avant deploiement ? Pour avoir pose la question recemment a une dizaine de RSSI dans des contextes varies, la reponse est uniformement : aucun.

Le risque supply chain demultiplie

L'autre face du probleme est l'integration MCP dans des produits tiers. Quand vous installez nginx-ui, vous heritez de son integration MCP. Quand vous activez un plugin pour votre IDE, idem. Quand votre SaaS de monitoring active une fonctionnalite IA, idem. Vous n'avez pas explicitement decide d'exposer un endpoint MCP, mais il est la, dans votre infrastructure, parce qu'un editeur en amont l'a juge utile.

Cette dynamique est exactement celle qui a produit les grands incidents supply chain recents : log4j, MOVEit, plus recemment la fuite Rockstar via Anodot. La difference avec MCP, c'est que la primitive sous-jacente est plus puissante. Un log4j vulnerable execute du code Java. Un endpoint MCP vulnerable execute des actions metier definies par le contexte. La premiere est detectable par un scan classique. La seconde necessite de comprendre le modele de capacites de chaque serveur MCP, ce que ni les SAST, ni les DAST, ni les outils CSPM actuels ne savent faire.

Mon avis d'expert

Le marche cybersecurite va devoir creer une nouvelle categorie d'outils dans les douze prochains mois : les MCP scanners et les MCP firewalls. C'est ineluctable. En attendant, la seule defense raisonnable, c'est l'inventaire force : toute equipe qui deploie un outil avec capacite MCP doit declarer explicitement les actions exposees, le perimetre d'authentification, et les controles compensatoires. Sans cela, on est en train de reediter dix ans plus tard les memes erreurs qu'avec les API REST exposees sans authentification dans les annees 2014-2016. Sauf que cette fois, l'attaquant ne lit pas vos donnees : il pilote votre infrastructure.

Conclusion

MCPwn ne sera pas la derniere CVE critique sur un serveur MCP. Elle est la premiere d'une serie qui va s'allonger durant 2026 et 2027 a mesure que le protocole s'enracinera dans la stack. Les organisations qui prendront le sujet au serieux des maintenant gagneront un avantage durable. Celles qui attendront d'etre touchees decouvriront que la remediation post-incident est, dans le cas de MCP, particulierement complexe : il ne s'agit pas seulement de patcher un binaire, il faut redesigner la facon dont les outils IA s'integrent au SI. Mieux vaut commencer maintenant.

Besoin d'un regard expert sur votre exposition MCP ?

Discutons de votre contexte specifique : cartographie des integrations IA, audit des endpoints MCP, durcissement.

Prendre contact