MCPwn (CVE-2026-33032) : un endpoint MCP de nginx-ui livre le serveur web

De quoi s’agit-il ?

CVE-2026-33032, baptisée MCPwn par Pluto Security, est un contournement d’authentification critique dans nginx-ui, l’interface web open source la plus utilisée pour administrer un serveur nginx. La faille réside dans l’intégration Model Context Protocol (MCP) récemment ajoutée au projet : l’un des deux endpoints HTTP MCP a été enregistré sans le middleware d’authentification qui protège toutes les autres routes d’administration.

La vulnérabilité a été identifiée par Pluto Security le 4 mars 2026, signalée aux mainteneurs le 14 mars et corrigée le lendemain dans la version 2.3.4 (15 mars 2026). Pluto a publié son analyse technique le 15 avril 2026, le CVE a rejoint le catalogue VulnCheck KEV (Known Exploited Vulnerabilities) le 13 avril 2026, et plusieurs éditeurs — Recorded Future, BleepingComputer, eSentire — ont confirmé une exploitation active en environnement réel dès la fin mars, avant que la plupart des opérateurs n’aient déployé le correctif. Le score CVSS est de 9.8 (critique).

Comment ça marche

Quand nginx-ui a ajouté le support MCP pour exposer ses actions d’administration à des agents LLM, deux endpoints HTTP ont été déclarés sur le routeur :

• POST /mcp — protégé par un filtrage d’IP et le middleware AuthRequired()
• POST /mcp_message — protégé par un filtrage d’IP uniquement

Les deux endpoints acceptent les mêmes charges utiles d’appel d’outils MCP. Le second a tout simplement perdu une ligne lors de l’enregistrement de la route :

// Schéma conceptuel de l'enregistrement de route vulnérable,
// basé sur la divulgation publique du 15 avril 2026 et le commit
// correctif 413dc63. Aucun payload contre un système en production
// n'est reproduit ici.

// Vulnérable (nginx-ui ≤ 2.3.3)
r.POST("/mcp",          middleware.IPWhiteList(), middleware.AuthRequired(), mcp.Handle)
r.POST("/mcp_message",  middleware.IPWhiteList(),                            mcp.Handle)
//                                                ^^^^^^^^^^^^^^^^^^^^^^^^^
//                                                AuthRequired() absent ici

// Corrigé (nginx-ui ≥ 2.3.4)
r.POST("/mcp",          middleware.IPWhiteList(), middleware.AuthRequired(), mcp.Handle)
r.POST("/mcp_message",  middleware.IPWhiteList(), middleware.AuthRequired(), mcp.Handle)

La seconde défense — le filtrage d’IP — ne sauve pas le déploiement, parce que la liste blanche d’IP par défaut est vide, et que le middleware traite une liste vide comme un allow-all plutôt qu’un deny-all. Tout opérateur qui a installé nginx-ui sans éditer manuellement la liste a exposé l’endpoint non authentifié à tous les réseaux d’où le service était joignable.

Parce que mcp_message accepte la totalité de la surface d’outils MCP, les conséquences ne se limitent pas à une fuite d’information. Un appelant non authentifié peut invoquer des outils qui créent, modifient ou suppriment des fichiers de configuration nginx, déclenchent un rechargement automatique de la configuration et redémarrent le service nginx — la définition manuelle d’une prise de contrôle complète du serveur web. Pluto a démontré la chaîne en deux requêtes HTTP.

Pourquoi c’est important

MCPwn est, autant que les sources publiques permettent d’en juger, le premier CVE largement exploité qui cible spécifiquement la surface d’attaque du Model Context Protocol — pas un bug web générique qui se trouve par hasard dans une pile LLM. La route vulnérable existe parce que le projet a choisi d’exposer des opérations d’administration à des agents IA via MCP, et le trou d’authentification se loge dans la couche de routage MCP elle-même.

Le motif va se répéter. Les serveurs MCP s’installent dans les outils de développement, les piles d’observabilité, les outils de ticketing, les IDE et les tableaux de bord d’infrastructure à un rythme nettement supérieur à la maturité de leurs modèles d’authentification. La spécification MCP d’Anthropic laisse le transport, l’authentification et la découverte assez peu définis, et chaque implémentation doit câbler ces pièces elle-même. Le projet nginx-ui a tout fait correctement sur ses routes d’administration historiques — la régression n’apparaît que sur les routes MCP ajoutées plus tard et relues avec moins d’attention.

L’autre enseignement porte sur les valeurs par défaut. Une liste blanche d’IP qui interprète une valeur vide comme « tout autoriser » est un piège dans lequel chaque administrateur finira par tomber. Le default-deny est le seul choix sûr pour tout contrôle dont l’intention explicite est de restreindre les accès.

Défenses

Mettez nginx-ui à jour vers 2.3.4 ou ultérieur immédiatement. Le correctif (commit 413dc63) ajoute middleware.AuthRequired() à /mcp_message et embarque un test de régression qui vérifie que /mcp et /mcp_message renvoient bien HTTP 403 sans authentification. L’exploitation active est confirmée depuis fin mars 2026 ; vous devez partir du principe que toute instance nginx-ui non patchée et joignable depuis Internet a été touchée, et auditer l’historique de configuration en conséquence.

Si vous ne pouvez pas patcher immédiatement, l’avis de Pluto Security documente deux contournements : ajouter manuellement middleware.AuthRequired() sur la route /mcp_message, ou changer la sémantique de la liste blanche d’IP pour qu’une liste vide signifie deny-all. L’un comme l’autre vaut mieux que laisser l’endpoint exposé.

Bloquez les endpoints MCP au niveau du reverse proxy en attendant le patch. Une règle NGINX ou Envoy qui renvoie 403 sur POST /mcp et POST /mcp_message tient quelques heures pendant la mise à niveau.

Auditez vos autres serveurs MCP pour la même classe de bug. Le motif — des routes MCP d’administration ajoutées à côté de routes historiques, dont une partie seulement reçoit le middleware d’authentification — se généralise. Faites un contrôle route par route : pour chaque serveur MCP de votre inventaire, listez tous les endpoints enregistrés, vérifiez que chacun est enveloppé par un middleware d’authentification, et écrivez un test qui s’assure que les appels non authentifiés renvoient 401/403. Traitez les routes MCP comme une surface d’administration de production, pas comme un module de debug.

Sortez les décisions de sécurité des listes blanches d’IP opt-in. Tout contrôle dont l’absence signifie « tout autoriser » est une régression en sursis. Default-deny, autorisation explicite.

Surveillez vos logs pour des POST non authentifiés sur /mcp_message avec des charges utiles d’appel d’outils référençant config_file, restart_nginx ou reload_config. Une exploitation réussie laisse des traces nettes dans le journal de requêtes de nginx-ui et dans les événements de rechargement de nginx lui-même.

Statut

Élément	Référence	Date	Notes
Découverte	Pluto Security	2026-03-04	Audit interne des routes MCP
Signalement amont	Mainteneurs nginx-ui prévenus	2026-03-14	Divulgation coordonnée
Version corrigée	nginx-ui 2.3.4 (commit 413dc63)	2026-03-15	Ajoute AuthRequired() + test de régression
Exploitation active observée	Recorded Future	2026-03 (fin)	Quelques jours après le patch
Ajout au KEV VulnCheck	VulnCheck	2026-04-13	Vulnérabilité activement exploitée
Divulgation publique	Avis Pluto Security + Rapid7 ETR	2026-04-15	« MCPwn », CVSS 9.8
Versions affectées	nginx-ui ≤ 2.3.3 (notice CVE : ≤ 2.3.5)	—	À vérifier contre votre version installée
Versions corrigées	nginx-ui ≥ 2.3.4	—	Mettre à jour et auditer les configs historiques

La leçon n’est pas que MCP serait dangereux en soi ; c’est que les endpoints MCP héritent de toutes les obligations de sécurité applicatives de l’hôte qui les expose, et que la course à l’expédition d’intégrations d’agents produit des bugs web classiques dans des endroits que personne ne scanne encore. Patchez nginx-ui, puis regardez le reste de votre flotte MCP avant qu’un autre ne le fasse à votre place.