MCP : la nouvelle surface d'attaque que personne n'audite

MCPwn n'est pas une faille isolée. C'est le premier signal sérieux d'une nouvelle catégorie de risques que personne dans les équipes sécurité ne regarde encore vraiment : 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 Model Context Protocol s'est invité dans des outils d'infrastructure critique — modification de configurations Nginx, déploiement de code, lecture de bases de données en production — avec la même insouciance qu'on déployait des API REST en 2014, avant que les Broken Object Level Authorization ne massacrent les bases clients. Sauf que cette fois, l'enjeu n'est pas une fuite de données d'API. C'est l'exécution d'actions privilégiées sur votre infrastructure, déclenchée depuis l'extérieur, via un protocole que personne dans votre équipe n'a eu le temps d'auditer. 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. Cet article pose le problème clairement et donne une grille d'action concrète.

MCP en production : le problème de fond est architectural

En six mois à peine, le Model Context Protocol est passé d'un protocole expérimental d'Anthropic à un standard de facto pour interfacer les LLM avec des outils internes. Le rythme d'adoption est spectaculaire : selon les statistiques GitHub d'avril 2026, plus de 15 000 dépôts publics contiennent une implémentation MCP. Des équipes DevOps déploient des serveurs MCP pour exposer leurs scripts d'astreinte aux agents IA. Des data engineers branchent leurs warehouses Snowflake. Des architectes exposent leurs outils de monitoring. Des RSSI eux-mêmes commencent à exposer leurs SIEM via MCP pour automatiser le triage d'alertes.

Le problème fondamental est que ces serveurs sont traités comme du code interne — donc supposés triviaux à sécuriser — alors qu'ils exécutent des actions privilégiées sur sollicitation distante. C'est une contradiction architecturale massive. Un serveur MCP n'est pas un service de données en lecture seule. C'est un endpoint qui exécute des intentions. Lire, écrire, exécuter, configurer — chaque outil exposé via MCP est une primitive d'action sur votre infrastructure.

L'analogie historique la plus pertinente est celle des serveurs Jenkins exposés sans authentification en 2017-2018. Des milliers d'instances avec auth désactivée — parfois par erreur, parfois par confort — qui ont servi de trampoline à des centaines de campagnes d'intrusion. Le risque MCP est potentiellement pire que Jenkins, pour une raison simple : les serveurs MCP sont conçus pour appeler des outils privilégiés. C'est leur fonction première, pas un effet de bord. La surface d'attaque est donc par construction plus large.

Ce que MCPwn nous apprend sur l'état réel du marché

La faille CVE-2026-33032 dans nginx-ui illustre parfaitement le problème. Le code coupable tient en quelques lignes : un middleware d'authentification correctement implémenté pour certaines routes, mais simplement non appelé sur le endpoint /mcp_message. Pas une vulnérabilité de cryptographie sophistiquée, pas un 0-day dans une bibliothèque tierce. Juste un oubli humain de configuration de middleware, du genre qu'un junior peut faire et qu'une revue de code attentive aurait dû attraper.

Ce qui rend cet oubli catastrophique dans le contexte MCP, c'est que l'endpoint /mcp_message d'nginx-ui permet de modifier des configurations Nginx et de recharger le serveur. Deux requêtes HTTP non authentifiées, et l'attaquant contrôle complètement la configuration de votre reverse proxy. Routes modifiées, backends redirigés, SSL terminaison manipulée. C'est une prise de contrôle complète de la couche réseau frontale.

Si ce type d'erreur triviale se cache dans nginx-ui — un projet open-source avec une communauté active et plusieurs milliers d'étoiles GitHub — combien d'implémentations MCP internes, codées rapidement par des équipes sans revue de sécurité dédiée, présentent les mêmes lacunes voire pires ?

La réponse, basée sur les audits que j'ai pu mener récemment, est : beaucoup. Pas parce que les développeurs sont incompétents. Parce que MCP est un protocole jeune, que la documentation de sécurité est encore lacunaire, et que les équipes qui l'implémentent en interne se concentrent sur les fonctionnalités — "ça marche, l'agent peut appeler l'outil" — sans penser systématiquement à la surface d'attaque.

Les trois lacunes structurelles que je vois systématiquement en audit

En auditant plusieurs SI qui ont déployé des serveurs MCP ces derniers mois, trois patterns reviennent avec une régularité qui commence à ressembler à une loi.

Lacune 1 — Authentification incohérente entre routes. C'est exactement le bug MCPwn, mais reproduit dans la majorité des templates communautaires MCP. Le middleware d'authentification est appliqué sur les routes principales mais oublié sur les routes secondaires — callback, webhook, health check, ou dans le cas MCP, les endpoints d'invocation d'outils. La cause racine est structurelle : dans les frameworks web modernes, l'authentification est souvent appliquée à des groupes de routes plutôt qu'à chaque route individuellement. Si l'endpoint MCP est ajouté après coup, hors du groupe protégé, il est exposé sans authentification.

Lacune 2 — Logs d'invocation absents ou insuffisants. Dans la majorité des implémentations MCP que j'ai auditées, les logs tracent les appels au serveur MCP (IP source, timestamp, endpoint) mais pas le détail de l'invocation : quel outil a été appelé, avec quels paramètres, par quel agent, avec quel résultat. Cette lacune de journalisation rend l'investigation post-incident quasi impossible et la détection d'abus en temps réel inexistante. Si quelqu'un exfiltre vos données via un outil MCP légitime avec des paramètres malicieux, votre SIEM ne voit rien.

Lacune 3 — Validation d'entrée déléguée au LLM. C'est la lacune la plus subtile et la plus grave. Certaines implémentations supposent que le modèle de langage qui invoque l'outil MCP est responsable de valider la légitimité des paramètres. Cette hypothèse est fondamentalement incorrecte pour deux raisons. D'abord, un attaquant qui contrôle le prompt peut manipuler le LLM pour lui faire générer des paramètres malicieux (prompt injection). Ensuite, même sans attaquant, un LLM peut générer des paramètres inattendus — un chemin de fichier avec des traversals, une commande avec des métacaractères shell — que le code de l'outil doit valider indépendamment. La validation d'entrée appartient au code de l'outil MCP, pas au modèle.

Le vrai débat : qui est responsable de la sécurité MCP ?

Quand un serveur MCP exposant des outils d'administration est compromis, l'attribution de responsabilité est un casse-tête réglementaire et organisationnel. Est-ce la faute du mainteneur open-source qui a oublié un middleware ? Du DevOps qui a déployé en production sans revue de sécurité ? Du RSSI qui n'a pas inclus MCP dans le périmètre d'audit ? De l'éditeur du LLM qui n'a pas suffisamment documenté les risques de sécurité de son protocole ?

Ce flou de responsabilité n'est pas accidentel — il est inhérent à la nouveauté du protocole et à la vitesse de son adoption. Les cadres réglementaires comme NIS 2 imposent des obligations de sécurité pour les entités essentielles, mais ils ne mentionnent pas explicitement les serveurs MCP. Les normes ISO 27001 et le NIST AI RMF couvrent la gouvernance des systèmes d'information et le management du risque IA, mais n'ont pas encore intégré la surface d'attaque spécifique aux protocoles d'interfaçage LLM.

Les pen-testers commencent à peine à intégrer les serveurs MCP dans leurs scopes d'audit. Les questionnaires de sécurité fournisseurs ne mentionnent pas encore les endpoints MCP. Et la plupart des outils SAST (analyse statique de code) ne savent pas identifier les patterns de vulnérabilité spécifiques aux implémentations MCP.

En pratique, la responsabilité revient à l'organisation qui déploie. Si vous opérez un serveur MCP en production, vous êtes responsable de sa sécurité — exactement comme vous l'êtes pour une API REST critique. Le fait que le protocole soit nouveau, que la documentation de sécurité soit incomplète, ou que votre équipe n'ait pas encore d'expertise MCP ne constitue pas une excuse opérationnelle. Ça peut atténuer la faute a posteriori, mais ça ne reconstruit pas les données exfiltrées.

Ce qu'il faut faire maintenant : la grille d'audit MCP

Voici la grille concrète que j'applique lors des audits d'infrastructure incluant des serveurs MCP. Elle n'est pas exhaustive — le domaine évolue trop vite — mais elle couvre les risques les plus immédiats.

Inventaire — Quels serveurs MCP tournent dans votre SI ? Un netstat -tnlp sur vos serveurs couplé à une recherche dans vos fichiers de configuration systemd et docker-compose identifie 80 % des instances. L'autre 20 % nécessite une analyse des logs réseau pour identifier les trafics sur les ports MCP standards (3000, 8080 et les ports customs documentés dans les configs déployées).

Authentification — Revue route par route. Pour chaque serveur MCP, lister tous les endpoints exposés et vérifier explicitement que le middleware d'authentification est appliqué à chacun. Ne pas supposer que le framework applique l'auth globalement — vérifier le code. Porter une attention particulière aux endpoints ajoutés après la mise en place initiale du serveur.

Journalisation — Audit de la complétude des logs. Les logs doivent capturer : timestamp, IP source, utilisateur authentifié ou agent IA, nom de l'outil invoqué, paramètres complets de l'invocation, résultat (succès/échec), durée d'exécution. Si un de ces éléments manque, la traçabilité forensique post-incident est compromise.

Validation d'entrée — Revue du code de chaque outil exposé. Pour chaque outil exposé via MCP, vérifier que la validation des paramètres d'entrée est implémentée dans le code de l'outil lui-même, indépendamment de ce que le LLM est supposé envoyer. Tests de traversal de chemin, d'injection de commandes, de paramètres hors limites.

Scope réseau — Qui peut appeler les endpoints MCP ? Aucun endpoint MCP ne doit être accessible depuis Internet sans authentification mTLS ou équivalent. Les endpoints internes doivent être restreints aux IP des agents IA légitimes. Un WAF ou un API gateway devant les endpoints MCP exposés est le minimum vital.

Conclusion

MCPwn est un avertissement, pas un accident isolé. Les six prochains mois verront l'apparition de plusieurs autres CVE majeures sur des frameworks MCP populaires, et probablement les premières campagnes d'exploitation automatisée ciblant spécifiquement les serveurs MCP exposés. Le scénario le plus probable : des scanners automatisés qui identifient les endpoints MCP exposés sur Internet, testent les configurations d'authentification défaillantes, et cataloguent les outils exposés pour exploitation ultérieure ou revente d'accès.

Si vous opérez un agent IA en production, l'inventaire de vos serveurs MCP doit figurer à votre prochain comité sécurité. Pas comme un sujet exploratoire ou prospectif — comme un risque concret et chiffré qui doit faire l'objet d'un plan d'action avec des dates. Pour approfondir, consultez notre analyse sur ISO 42001 et le management de l'IA ainsi que notre dossier sur les outils de sécurité devenus le risque principal.

Controles de securite MCP a implanter en priorite

Les equipes securite qui decouvrent MCP dans leur perimetre d'audit ont besoin de controles concrets deployables rapidement, sans attendre une gouvernance complete. Le premier niveau de defense consiste a inventorier exhaustivement les serveurs MCP actifs dans l'infrastructure, tache plus difficile qu'il n'y parait car ces serveurs sont souvent demarres localement par des developpeurs sans procedure d'enregistrement formelle, creant des actifs shadow IT dans la zone LLM. Un scan reseau combine a une revue des configurations des postes developpeurs et des serveurs de build constitue le point de depart de cet inventaire initial.

L'authentification et l'autorisation des appels MCP constituent le deuxieme niveau de controle prioritaire. En l'absence de standard unifie pour l'authentification MCP, les implementations varient considerablement d'un serveur a l'autre : certains exposent des endpoints non authentifies sur localhost en supposant que l'acces reseau suffit comme controle, d'autres implementent des tokens API statiques ou des certificats mutuels TLS. L'audit doit verifier que chaque serveur MCP exige une authentification forte, que les tokens sont rotes regulierement selon une politique definie, et que les appels non authentifies sont rejetes avec des logs d'alerte generes en temps reel vers le SIEM de l'organisation.

La validation des inputs cote serveur MCP est une mesure defensive critique contre les attaques par prompt injection et les abus d'autorisation. Tout contenu manipule par l'utilisateur final qui transite via un appel d'outil MCP doit etre valide et assaini avant execution : URL, chemins de fichiers, requetes de recherche, parametres d'API. Les patterns d'injection exploitent l'absence de validation pour faire executer par le serveur des actions non prevues, comme lire des fichiers systeme sensibles ou acceder a des ressources hors du perimetre autorise par la politique de securite.

La journalisation et la surveillance des appels MCP doivent etre integrees dans le SIEM. Chaque appel d'outil doit generer un log structure avec l'identite de l'appelant, le nom de l'outil invoque, les parametres passes avec masquage des donnees sensibles, le resultat retourne et l'horodatage precis. Ces logs permettent de detecter les comportements anormaux : volume d'appels inhabituel, acces a des outils rarement utilises, tentatives d'acces hors perimetre. Les regles de detection SIGMA pour les appels MCP suspects emergent dans les depots communautaires et meritent d'etre integrees dans les playbooks de detection de votre SOC.

Vers une gouvernance MCP de niveau enterprise

Les organisations qui ont depasse la phase de decouverte et de mitigation d'urgence commencent a construire une gouvernance perenne autour de la couche MCP. Cette gouvernance repose sur trois piliers : un catalogue officiel des serveurs MCP approuves, une procedure d'onboarding des nouveaux serveurs avec revue de securite obligatoire, et une politique d'utilisation acceptable pour les agents IA en production definissant clairement ce que ces agents peuvent et ne peuvent pas faire au nom de l'organisation. Sans ce cadre, la proliferation non gouvernee des outils MCP reproduit les problemes d'IT shadow que les entreprises ont mis des annees a juguler dans le cloud.

Le catalogue des serveurs MCP approuves doit documenter pour chaque entree le proprietaire fonctionnel, les ressources auxquelles le serveur accede, le perimetre d'autorisation accorde, la frequence de revue de securite planifiee et les resultats du dernier test ou revue de code. Ce catalogue est un actif de securite vivant qui doit etre mis a jour lors de chaque modification de serveur et forme la base du registre MCP qui sera probablement exige par les futures reglementations europeennes sur l'IA et les systemes agentiques.

La separation stricte des environnements est un principe d'architecture essentiel pour les deployments MCP en production. Les serveurs MCP de developpement et de test ne doivent jamais avoir acces aux ressources de production, ni partager des credentials ou tokens avec l'environnement de production. Cette separation est regulierement contournee en pratique par des configurations de commodite qui creent des chemins d'acces croises. L'audit doit verifier la rigueur de cette separation, documenter les mecanismes d'isolation reseau et applicative mis en place et confirmer que les revues periodiques de cette isolation sont realisees et tracees.

Maturite de la securite MCP et roadmap d'amelioration continue

La securite MCP n'est pas un etat a atteindre une fois pour toutes mais un processus d'amelioration continue analogue a tout autre programme de cybersecurite mature. Les organisations les plus avancees definissent un modele de maturite MCP propre, avec des niveaux progressifs allant de la simple visibilite des serveurs deployes jusqu'a l'orchestration securisee multi-agents avec isolation des contextes et audit complet des decisions prises par les agents IA en production.

L'integration des tests de securite specifiques MCP dans les programmes de red team existants est une etape importante de cette maturite. Les scenarios de test incluent des tentatives de prompt injection via les outils MCP, des tests de privilege escalation via la chaine d'outils, des tests de data exfiltration via des serveurs MCP compromis et des evaluations de la robustesse des mecanismes d'authentification sous charge. Ces tests permettent de mesurer objectivement la solidite des controles implementes et d'identifier les lacunes restantes avant qu'elles ne soient exploitees par des acteurs malveillants reels.