En 48 heures cette semaine, deux vulnérabilités CVSS 10 et 9.8 ont frappé des plateformes d'administration très populaires : n8n et nginx-ui. Même cause, mêmes effets. Le coupable ? Le Model Context Protocol — ou plutôt, la façon dont les éditeurs l'ont greffé sur des produits qui n'étaient pas pensés pour ça.

Le MCP, c'est quoi et pourquoi tout le monde s'est jeté dessus

Anthropic a publié le Model Context Protocol fin 2024 pour standardiser la façon dont un modèle de langage peut invoquer des outils externes : lire un fichier, exécuter une commande, pousser une config. En 18 mois, quasiment tous les éditeurs de dev-tools et d'infrastructure ont branché un serveur MCP sur leur produit. nginx-ui l'a fait pour permettre à Claude ou Cursor de modifier des configurations Nginx depuis un prompt. n8n pour que l'IA déclenche des workflows. Docker Desktop, PostgreSQL, GitHub, tous y sont allés.

Le problème, c'est que le 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. La quasi-totalité des implémentations que je vois sur le terrain exposent pourtant ces endpoints soit sur le réseau local, soit pire, publiquement. Avec une sécurité bricolée à la volée.

Deux CVE en 72 h, même schéma

CVE-2026-33032 sur nginx-ui : un endpoint /mcp_message accepte les requêtes non authentifiées parce que la whitelist IP par défaut est vide, et le middleware interprète ça comme « tout le monde est autorisé ». Deux requêtes HTTP et l'attaquant a le contrôle du serveur Nginx. CVE-2026-21858 sur n8n : un formWebhook qui ne valide pas le Content-Type et permet l'injection de chemins de fichiers arbitraires, exfiltrés via le nœud LLM en aval.

Dans les deux cas, ce ne sont pas des bugs isolés. Ce sont des décisions de conception : exposer des capacités de manipulation système à un protocole neuf, mal maîtrisé, sans penser la surface d'attaque comme on l'aurait fait pour une API REST classique. Et quand le produit est déployé 100 000 fois comme n8n, ou 2 700 fois directement exposé à Internet comme nginx-ui, la fenêtre d'exploitation est énorme.

Ce qu'on voit vraiment côté audit

Quand j'audite un SI moderne aujourd'hui, je trouve du MCP partout. Un agent IA qui peut redémarrer des services via un serveur MCP Docker. Un workflow qui pilote des tickets Jira via un MCP. Un « copilote » interne qui peut exécuter des requêtes SQL en production. Tout ça est branché sur des clés d'API qui traînent dans des fichiers .env, 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.

La plupart des équipes sécu que je rencontre n'ont pas encore intégré MCP à leur cartographie. 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, pas de détection SOC adaptée. 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é à massacrer les bases clients.

Les trois choses à faire dès cette semaine

Premièrement, une cartographie : quelles machines hébergent des serveurs MCP, quels ports, exposés à quoi. Un simple netstat -tnlp couplé à un grep sur systemctl fait déjà 80 % du travail. Deuxièmement, une règle simple : aucun endpoint MCP ne doit être accessible au-delà du loopback sans authentification explicite et IP whitelisting non-vide. Troisièmement, une détection : si un endpoint MCP reçoit du trafic qui ne provient pas de votre IDE ou de votre serveur IA interne, c'est une alerte. Point.

Mon avis d'expert

Le MCP est techniquement solide mais déployé avec la même insouciance que les API SOAP il y a 15 ans. On va voir passer 10 à 15 CVE similaires dans les 6 prochains mois avant que les éditeurs reprennent leurs copies. En attendant, chaque RSSI doit considérer les serveurs MCP comme des surfaces d'admin à part entière et non comme des gadgets de productivité. Si un MCP tombe, il donne les clés exactement comme un SSH root compromis.

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, ouvrez les ports, cherchez, et dormez un peu moins bien cette nuit. C'est le prix à payer pour rattraper le retard avant les attaquants.

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

Discutons de votre contexte spécifique — cartographie MCP, audit d'exposition, durcissement des agents IA internes.

Prendre contact