MCPwn n'est pas une faille isolée. C'est le premier signal sérieux d'une nouvelle catégorie de risques : les serveurs MCP exposés sans audit, multipliés par dix en six mois, pilotés par des équipes qui copient des templates open-source sans relire les middlewares. Le pattern est exactement celui qu'on a connu avec les premières API REST en 2014, sauf que cette fois les outils invoqués modifient des configs Nginx, déploient du code, lisent des fichiers ou interrogent des bases de données en production. Et personne ne regarde. Pendant que les RSSI s'occupent encore d'écrire leurs politiques d'usage de ChatGPT, l'écosystème MCP a déjà glissé dans la production sans gouvernance, sans inventaire, sans audit. Cet article propose un état des lieux et une grille de lecture pour les six prochains mois, à destination des architectes sécurité qui veulent éviter de découvrir leurs serveurs MCP au moment où ils sont déjà compromis.

Le problème de fond : MCP est devenu de l'infrastructure

En six mois, MCP est passé d'un protocole expérimental d'Anthropic à un standard de facto pour interfacer les LLM avec des outils internes. Les équipes DevOps déploient des serveurs MCP pour exposer leurs scripts d'astreinte aux agents IA. Les data engineers branchent leurs warehouses Snowflake. Les RSSI eux-mêmes commencent à exposer leurs SIEM via MCP pour automatiser le triage. Le problème, c'est que ces serveurs sont traités comme du code interne — donc considérés comme triviaux à sécuriser — alors qu'ils exécutent des actions privilégiées sur sollicitation distante.

Ce que MCPwn nous apprend

La faille CVE-2026-33032 dans nginx-ui tient en une ligne de code : un middleware d'authentification non appelé sur le endpoint /mcp_message. Pas une vulnérabilité subtile, pas un 0-day complexe, juste un oubli humain. Si ce type d'erreur se cache dans un projet open-source aussi visible, combien d'instances internes — codées à la va-vite, jamais auditées — présentent les mêmes lacunes ?

L'analogie historique la plus parlante est celle des Jenkins exposés en 2017-2018 : milliers d'instances avec auth désactivée, parfois par erreur, parfois par confort, qui ont servi de tremplin à des centaines d'attaques. Le risque MCP est pire car les serveurs MCP sont conçus pour appeler des outils privilégiés. C'est leur fonction, pas un effet de bord.

Trois lacunes structurelles que je vois en audit

Trois patterns reviennent systématiquement dans les audits que j'ai pu mener ces dernières semaines :

  • Authentification incohérente entre routes — exactement le bug MCPwn, dupliqué dans la majorité des templates communautaires
  • Logs d'invocation absents ou anonymisés — impossible de tracer quel agent a appelé quel outil avec quels paramètres
  • Validation d'entrée déléguée au LLM — la sanitization repose sur le bon vouloir du modèle, ce qui ouvre la porte aux prompt injections qui forgent des arguments malveillants

Le vrai débat : qui est responsable ?

Quand un MCP exposant des outils admin est compromis, à qui imputer la faute ? Au mainteneur open-source qui a oublié un middleware ? Au DevOps qui a déployé sans relecture ? Au RSSI qui n'a pas inscrit MCP dans son périmètre d'audit ? Ce flou de responsabilité est précisément ce qui rend la situation explosive. Les frameworks d'IA sécurisée (NIST AI RMF, ISO 42001) ne couvrent pas explicitement les serveurs MCP. Les pen-testers commencent à peine à intégrer ces cibles dans leurs scopes.

Mon avis d'expert

Tout serveur MCP exposant plus de trois outils mérite un audit dédié, au même titre qu'une API REST critique. Le minimum vital : revue de tous les middlewares route par route, authentification mTLS plutôt que tokens partagés, journalisation exhaustive avec corrélation utilisateur-agent-outil-paramètres, et tests d'intrusion incluant des scénarios de prompt injection. Ne déléguez pas la sécurité MCP à votre fournisseur de LLM — c'est votre infrastructure, votre responsabilité.

Conclusion

MCPwn est un avertissement, pas un cas isolé. Les six prochains mois verront l'apparition de plusieurs autres CVE majeures sur des frameworks MCP populaires, et probablement la première campagne ransomware ciblant spécifiquement des serveurs MCP exposés. Si vous opérez un agent IA en production, l'inventaire de vos serveurs MCP doit figurer dans votre prochain comité sécurité. Pas comme un sujet exploratoire — comme un risque concret et chiffré. Pour aller plus loin, consultez notre dossier ISO 42001 et management de l'IA ainsi que notre analyse des outils de sécurité devenus le risque principal.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique.

Prendre contact