MCP, l'angle mort 2026 : quand l'admin devient backdoor

En 48 heures cette semaine d'avril 2026, deux vulnérabilités CVSS 10 et 9.8 ont frappé deux plateformes d'administration très populaires : n8n (plus de 100 000 déploiements actifs selon les statistiques Docker Hub) et nginx-ui (plusieurs milliers d'instances exposées directement sur Internet selon Shodan). Même cause profonde, mêmes effets catastrophiques. Le coupable dans les deux cas ? Le Model Context Protocol — ou plus précisément, la façon dont des éditeurs l'ont greffé en urgence sur des produits qui n'avaient pas été pensés pour ça, sans revue de sécurité sérieuse, sans pentest des endpoints MCP, sans même une analyse de surface d'attaque basique. Ce n'est pas une coïncidence. C'est le début d'une vague. Et si votre SOC n'a pas encore commencé à chercher les serveurs MCP dans votre périmètre, vous dormez à côté d'une bombe dont vous ne connaissez pas le minuteur.

MCP : ce que c'est et pourquoi tout le monde s'est précipité

Anthropic a publié le Model Context Protocol fin novembre 2024 pour standardiser la façon dont un modèle de langage peut invoquer des outils externes : lire un fichier, exécuter une commande, modifier une configuration, déclencher un workflow, interroger une base de données. L'idée est techniquement solide : plutôt qu'une jungle d'intégrations propriétaires pour chaque combinaison modèle-outil, un protocole standardisé qui permet à n'importe quel agent IA compatible d'utiliser n'importe quel outil MCP compatible.

En 18 mois, quasiment tous les éditeurs de dev-tools et d'infrastructure ont sauté dans le train. nginx-ui l'a fait pour permettre à Claude, Cursor ou Copilot de modifier des configurations Nginx depuis un prompt en langage naturel. n8n pour que l'IA déclenche et orchestre des workflows complexes. Docker Desktop pour permettre de gérer des conteneurs par la parole. PostgreSQL, GitHub, Kubernetes — tous y sont allés. Et pour cause : l'intégration MCP est une feature qui se vend bien, qui satisfait les utilisateurs qui veulent faire de l'"IA native", et qui se code relativement vite à partir des SDK disponibles.

Le problème, c'est que MCP a été conçu comme un protocole client-serveur local, pour un développeur qui fait tourner son IDE et ses outils sur la même machine dans un contexte de développement isolé. La quasi-totalité des implémentations que je vois sur le terrain exposent ces endpoints soit sur le réseau local, soit pire, publiquement sur Internet. Avec une sécurité conçue à la va-vite, bricolée sur une infrastructure qui n'a jamais vu un pen-test axé sur la surface MCP.

Deux CVE en 72 heures, même schéma : l'analyse technique

CVE-2026-33032 sur nginx-ui (CVSS 10.0). Le code est public sur le dépôt GitHub de nginx-ui : l'endpoint /api/mcp_message est déclaré dans le routeur, mais le middleware d'authentification JWT qui protège les autres routes n'est pas appliqué à cet endpoint. La whitelist IP, supposée filtrer l'accès, est initialisée avec un tableau vide — et la logique de vérification interprète un tableau vide comme "aucune restriction". Résultat : n'importe qui sur Internet peut envoyer une requête POST à /api/mcp_message et déclencher n'importe quel outil exposé par nginx-ui, notamment la modification de la configuration nginx et le rechargement du serveur.

Impact concret : modification des règles de reverse proxy (redirection du trafic vers des backends malicieux), modification des headers de sécurité, exposition de backends normalement masqués, ou simplement DoS via rechargement en boucle. Une attaque automatisable en une dizaine de lignes de Python. Délai entre publication de la CVE et premier exploit documenté dans les honeypots Shadowserver : moins de 4 heures.

CVE-2026-21858 sur n8n (CVSS 9.8). Le bug est différent mais la famille est identique — une validation d'entrée absente sur un endpoint MCP. Le formWebhook de n8n ne valide pas le Content-Type et ne sanitise pas le champ de chemin de fichier dans les requêtes entrantes. Un attaquant peut injecter un chemin arbitraire — avec traversal (../../etc/passwd) ou chemin absolu (/var/run/secrets/kubernetes.io/serviceaccount/token) — qui est ensuite traité par le nœud LLM en aval et exfiltré dans la réponse ou dans les logs d'exécution du workflow.

Dans les déploiements Kubernetes de n8n, le token de service account Kubernetes est accessible à ce chemin par défaut. Un attaquant qui exfiltre ce token peut potentiellement accéder à l'API Kubernetes avec les permissions du pod n8n — souvent surélevées pour permettre à n8n d'orchestrer des ressources Kubernetes. Escalade depuis une lecture de fichier vers un contrôle partiel ou complet du cluster.

Dans les deux cas, ce ne sont pas des bugs d'implémentation subtils. Ce sont des décisions de conception défaillantes : exposer des capacités de manipulation système via un protocole neuf, sans appliquer les principes élémentaires de sécurité des API (authentification systématique, validation d'entrée, principe de moindre privilege).

Ce qu'on voit vraiment côté audit : l'état réel du terrain

Quand j'audite un SI moderne en 2026, je trouve du MCP partout. Pas de manière organisée et documentée — de manière organique et invisible. Un agent IA interne branché sur un serveur MCP Docker qui peut redémarrer des services. Un workflow n8n qui pilote des tickets Jira et déclenche des déploiements via API. Un "copilote" interne connecté à une base de données de production pour répondre aux questions des analystes. Un outil de monitoring qui expose ses actions de remédiation via MCP pour qu'un agent IA puisse répondre automatiquement aux alertes.

Tout ça est branché sur des clés d'API qui traînent dans des fichiers .env non chiffrés, sur des ports ouverts qui n'ont jamais été déclarés dans le périmètre audité, sur des services systemd non référencés dans la CMDB, et avec des logs d'invocation soit absents soit tellement verbeux qu'ils ne sont jamais analysés.

La plupart des équipes sécurité que je rencontre n'ont pas encore intégré MCP à leur cartographie de la surface d'attaque. Elles n'ont pas de politique sur ce qui peut ou ne peut pas exposer un endpoint MCP. Pas de revue de code spécifique aux implémentations MCP. Pas de règle de détection SOC ciblant le trafic MCP anormal. On est exactement dans la même situation qu'avec les API REST au début des années 2010 : tout le monde en ajoutait sans supervision, jusqu'au jour où les Broken Object Level Authorization ont commencé à exposer des bases clients entières. La différence avec MCP, c'est que l'impact n'est pas la lecture de données — c'est l'exécution d'actions sur l'infrastructure.

La cartographie que votre équipe doit faire cette semaine

L'inventaire MCP de votre SI doit être traité avec la même urgence qu'un inventaire de services exposés sur Internet après un incident. Voici la méthode.

Étape 1 — Identification des processus MCP actifs. Sur chaque serveur : netstat -tnlp | grep LISTEN suivi d'une analyse des processus qui écoutent sur des ports non standards. Les ports MCP les plus courants sont 3000, 3001, 8080, 8443, et des ports customs définis dans les configurations des outils déployés. Un ss -tlnp plus moderne donne le même résultat avec le nom du processus.

Étape 2 — Identification des configurations MCP dans les dépôts. Via les API GitHub/GitLab, rechercher tous les fichiers contenant "mcpServers" ou "mcp_message" ou "/mcp" dans les dépôts de l'organisation. Ces patterns identifient les configurations de serveurs MCP et les endpoints exposés. Inclure les fichiers .claude/settings.json, mcp.json, claude_desktop_config.json.

Étape 3 — Test d'authentification sur les endpoints trouvés. Pour chaque endpoint MCP identifié, tester l'accès sans token, avec un token invalide, et avec un token d'un utilisateur sans droits. Tout endpoint qui répond positivement à l'une de ces requêtes est vulnérable et doit être traité en P0 immédiat.

Étape 4 — Revue des outils exposés. Pour chaque serveur MCP authentifié, lister les outils disponibles (via la méthode tools/list du protocole MCP) et évaluer l'impact potentiel de chaque outil. Un outil qui peut exécuter des commandes shell ou modifier des fichiers est une surface d'attaque critique, indépendamment de la qualité de l'authentification.

Les trois règles non négociables pour tout déploiement MCP

Règle 1 — Authentification systématique sur tous les endpoints, sans exception. Aucun endpoint MCP ne doit accepter des requêtes sans authentification valide, quelle que soit son emplacement dans le code (route principale ou sous-route). La revue de code doit vérifier explicitement que le middleware d'authentification est appliqué à tous les endpoints MCP, pas seulement aux endpoints documentés.

Règle 2 — Validation d'entrée dans le code de l'outil, pas dans le LLM. Tout outil MCP qui accepte des paramètres de fichiers, de commandes, ou de chemins doit valider ces paramètres indépendamment de ce que le LLM est supposé envoyer. La liste blanche des commandes autorisées, la validation des traversals de chemin, la sanitisation des métacaractères shell — tout cela doit être dans le code de l'outil, pas supposé implicitement.

Règle 3 — Exposition minimale et journalisation complète. Un endpoint MCP ne doit être accessible que depuis les IP des agents IA légitimes, jamais depuis Internet directement. Les logs d'invocation doivent capturer : timestamp, IP source, utilisateur/agent authentifié, nom de l'outil, paramètres complets, résultat. Sans cette journalisation, l'investigation post-incident est impossible.

Ce que votre équipe SOC doit détecter maintenant

En attendant que les éditeurs patchent et que les politiques se formalisent, voici les règles de détection concrètes à déployer dans votre SIEM pour couvrir les vecteurs MCP les plus courants.

Règle 1 — Requêtes vers des ports MCP non documentés. Toute connexion vers les ports 3000, 3001, 8080 sur des serveurs internes depuis des IP extérieures au réseau d'agents IA approuvés doit déclencher une alerte. Si vous n'avez pas encore de liste des agents IA approuvés dans votre SIEM, commencez par logger tout le trafic vers ces ports — l'analyse du volume et des patterns permettra de rapidement identifier les anomalies.

Règle 2 — Invocations d'outils à impact élevé en dehors des plages horaires habituelles. Les agents IA légitimes fonctionnent généralement pendant les heures de travail des équipes qui les utilisent. Une invocation d'outil MCP qui modifie des configurations réseau à 3h du matin un dimanche est un signal d'alarme fort. Corréler les logs d'invocation MCP (si vous les collectez) avec les plages horaires habituelles d'activité de l'agent légitime.

Règle 3 — Volume anormalement élevé d'invocations MCP en rafale. Les exploitations automatisées de endpoints MCP vulnérables génèrent généralement un volume d'invocations très supérieur à l'usage légitime. Un seuil de volumétrie par IP source et par plage de 10 minutes permet de détecter les scans de masse et les exploitations automatisées.

Conclusion

Le MCP n'est pas le problème. La précipitation avec laquelle il a été greffé sur des produits conçus avant son existence, oui. Les deux CVE de cette semaine ne sont qu'un avant-goût. Si vous n'avez pas encore regardé ce que votre SI expose en MCP, commencez maintenant : un netstat, un grep dans vos dépôts, et un test d'authentification sur les endpoints trouvés. C'est une heure de travail qui pourrait vous éviter de vous retrouver à expliquer comment des attaquants ont modifié vos configurations Nginx via un endpoint que personne dans votre équipe ne savait qu'il existait.