sistema: OPERATIVO
← volver a todos los hacks
INFRASTRUCTURE CRITICAL NEW

MCPwn (CVE-2026-33032): un endpoint MCP de nginx-ui entrega el servidor web

Un endpoint MCP sin autenticación en nginx-ui ≤ 2.3.3 permite que cualquier atacante de red reescriba configuraciones de nginx y reinicie el servicio. CVSS 9.8, divulgación pública el 15 de abril de 2026, explotación en entorno real horas después del parche.

2026-05-29 // 7 min affects: nginx-ui, mcp-servers, model-context-protocol

¿De qué se trata?

CVE-2026-33032, bautizada MCPwn por Pluto Security, es un bypass de autenticación crítico en nginx-ui, la interfaz web open source más utilizada para administrar servidores nginx. El fallo reside en la integración Model Context Protocol (MCP) añadida recientemente al proyecto: uno de los dos endpoints HTTP MCP se registró sin el middleware de autenticación que protege todas las demás rutas administrativas.

La vulnerabilidad fue identificada por Pluto Security el 4 de marzo de 2026, reportada a los mantenedores el 14 de marzo y corregida al día siguiente en la versión 2.3.4 (15 de marzo de 2026). Pluto publicó su análisis técnico el 15 de abril de 2026, el CVE ingresó al catálogo VulnCheck KEV (Known Exploited Vulnerabilities) el 13 de abril de 2026, y varios proveedores — Recorded Future, BleepingComputer, eSentire — confirmaron explotación activa en entornos reales desde finales de marzo, antes de que la mayoría de los operadores hubiesen desplegado el parche. La puntuación CVSS es 9.8 (crítica).

Cómo funciona

Cuando nginx-ui añadió soporte MCP para exponer sus acciones administrativas a agentes LLM, se declararon dos endpoints HTTP en el enrutador:

  • POST /mcp — protegido por una lista blanca de IP y el middleware AuthRequired()
  • POST /mcp_message — protegido por una lista blanca de IP únicamente

Ambos endpoints aceptan las mismas cargas útiles de llamadas a herramientas MCP. El segundo simplemente perdió una línea durante el registro de la ruta:

// Esquema conceptual del registro de ruta vulnerable, basado en
// la divulgación pública del 15 de abril de 2026 y el commit del
// parche 413dc63. No se reproduce aquí ningún payload contra un
// sistema en producción.

// Vulnerable (nginx-ui ≤ 2.3.3)
r.POST("/mcp",          middleware.IPWhiteList(), middleware.AuthRequired(), mcp.Handle)
r.POST("/mcp_message",  middleware.IPWhiteList(),                            mcp.Handle)
//                                                ^^^^^^^^^^^^^^^^^^^^^^^^^
//                                                AuthRequired() ausente aquí

// Parcheado (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 segunda defensa — la lista blanca de IP — no salva el despliegue, porque la lista por defecto se entrega vacía, y el middleware trata una lista vacía como allow-all y no como deny-all. Todo operador que instaló nginx-ui sin editar manualmente la lista expuso el endpoint sin autenticación a todas las redes desde las que el servicio era accesible.

Como mcp_message acepta toda la superficie de herramientas MCP, las consecuencias no se limitan a una fuga de información. Una llamada sin autenticación puede invocar herramientas que crean, modifican o eliminan archivos de configuración de nginx, disparan una recarga automática de la configuración y reinician el servicio nginx — la definición de manual de una toma de control completa del servidor web. Pluto demostró la cadena en dos peticiones HTTP.

Por qué importa

MCPwn es, hasta donde permiten ver las fuentes públicas, el primer CVE ampliamente explotado que apunta específicamente a la superficie de ataque del Model Context Protocol — no un bug web genérico que casualmente vive dentro de una pila LLM. La ruta vulnerable existe porque el proyecto decidió exponer operaciones administrativas a agentes IA mediante MCP, y el hueco de autenticación se sitúa en la capa de enrutamiento MCP misma.

El patrón se va a repetir. Los servidores MCP están aterrizando en herramientas de desarrollo, pilas de observabilidad, sistemas de tickets, IDE y paneles de infraestructura a un ritmo bastante superior a la madurez de sus modelos de autenticación. La especificación MCP de Anthropic deja transporte, autenticación y descubrimiento bastante poco definidos, y cada implementación tiene que cablear esas piezas por su cuenta. El proyecto nginx-ui hizo todo correctamente en sus rutas administrativas históricas — la regresión solo aparece en las rutas MCP añadidas más tarde y revisadas con menos atención.

La otra lección tiene que ver con los valores por defecto. Una lista blanca de IP que interpreta un valor vacío como “permitir a todos” es una trampa en la que cada administrador acabará cayendo. Default-deny es la única opción segura para todo control cuya intención explícita es restringir el acceso.

Defensas

Actualice nginx-ui a 2.3.4 o posterior de inmediato. El parche (commit 413dc63) añade middleware.AuthRequired() a /mcp_message y embarca un test de regresión que verifica que /mcp y /mcp_message devuelven HTTP 403 sin autenticación. La explotación activa está confirmada desde finales de marzo de 2026; asuma que cualquier nginx-ui sin parchear y accesible desde Internet ha sido tocado, y audite el historial de configuración en consecuencia.

Si no puede parchear de inmediato, el aviso de Pluto Security documenta dos workarounds: añadir manualmente middleware.AuthRequired() a la ruta /mcp_message, o cambiar la semántica de la lista blanca de IP para que una lista vacía signifique deny-all. Cualquiera de los dos es preferible a dejar el endpoint expuesto.

Bloquee los endpoints MCP en el reverse proxy mientras parchea. Una regla corta de NGINX o Envoy que devuelva 403 para POST /mcp y POST /mcp_message aguanta unas horas durante la actualización.

Audite sus otros servidores MCP en busca de la misma clase de bug. El patrón — rutas MCP administrativas añadidas junto a rutas históricas, solo algunas de ellas recibiendo el middleware de autenticación — se generaliza. Haga un control ruta a ruta: para cada servidor MCP de su inventario, liste todos los endpoints registrados, confirme que cada uno está envuelto por un middleware de autenticación y escriba un test que verifique que las llamadas sin autenticación devuelven 401/403. Trate las rutas MCP como superficie administrativa de producción, no como un módulo de debug.

Saque las decisiones de seguridad de las listas blancas de IP opt-in. Todo control cuya ausencia significa “permitir a todos” es una regresión en suspenso. Default-deny, autorización explícita.

Vigile sus registros en busca de POST sin autenticación a /mcp_message con cargas útiles de llamadas a herramientas que referencien config_file, restart_nginx o reload_config. Una explotación exitosa deja trazas claras en el log de peticiones de nginx-ui y en los eventos de recarga del propio nginx.

Estado

ElementoReferenciaFechaNotas
DescubrimientoPluto Security2026-03-04Auditoría interna de rutas MCP
Reporte upstreamMantenedores de nginx-ui avisados2026-03-14Divulgación coordinada
Versión corregidanginx-ui 2.3.4 (commit 413dc63)2026-03-15Añade AuthRequired() + test de regresión
Explotación activa observadaRecorded Future2026-03 (fines)A pocos días del parche
Añadido al KEV de VulnCheckVulnCheck2026-04-13Vulnerabilidad activamente explotada
Divulgación públicaAviso Pluto Security + Rapid7 ETR2026-04-15”MCPwn”, CVSS 9.8
Versiones afectadasnginx-ui ≤ 2.3.3 (registro CVE: ≤ 2.3.5)Verificar contra su versión instalada
Versiones parcheadasnginx-ui ≥ 2.3.4Actualizar y auditar configuraciones históricas

La lección no es que MCP sea inseguro en sí mismo; es que los endpoints MCP heredan todas las obligaciones de seguridad aplicativa del host que los expone, y la prisa por sacar integraciones de agentes está produciendo bugs web clásicos en lugares que nadie está escaneando todavía. Parchee nginx-ui y luego mire al resto de su flota MCP antes de que otro lo haga por usted.

Sources