El servidor de desarrollo de Next.js ahora tiene su propia superficie de ataque: qué cambia realmente el parche del endpoint MCP
Next.js 16.3.8 y 15.5.27 parchean siete vulnerabilidades publicadas el 30 de septiembre, incluida CVE-2026-94486: el endpoint MCP de `next dev` permite que cualquier web que abra el desarrollador lea rutas, inventario de endpoints y logs del proyecto. La matriz de triaje de las siete y el modelo de exposición que usamos con agentes de IA.
El servidor de desarrollo de Next.js ahora tiene su propia superficie de ataque: qué cambia realmente el parche del endpoint MCP
El 30 de septiembre Next.js publicó 16.3.8 y 15.5.27 con correcciones para siete vulnerabilidades. Seis viven en rutas de producción; la séptima — CVE-2026-94486 — vive en el endpoint de Model Context Protocol del servidor de desarrollo, y permite que cualquier web que el desarrollador abra en su navegador lea la ruta del proyecto en disco, el inventario de rutas, fragmentos de código de los reportes de error y los logs de next dev. Vercel la calificó como Low (2.3/10) porque producción no sirve ese endpoint. Esa calificación está escrita para un humano con un navegador abierto; deja de ser toda la historia en cuanto next dev queda corriendo al lado de un agente de IA durante horas.
Esa es la respuesta directa. Lo que sigue es el triaje real de las siete vulnerabilidades, por qué la de menor severidad es la que más dice de cómo trabajamos ahora, y las reglas que aplicamos nosotros cada vez que un agente toca un servidor de desarrollo.
Lo que salió el 30 de septiembre (y por qué el 29 no valió)
El advisory oficial de Next.js confirma los dos versiones parchadas: npm install [email protected] para la LTS activa y [email protected] para la LTS de mantenimiento. Un detalle que muchos se saltaron: un día antes, Vercel publicó 16.3.7 con un fix de bugs que no incluía los fixes de seguridad — la nota de anuncio previo avisaba que el lanzamiento quedó retrasado por una dependencia upstream. Si tu proceso de parcheo decide "actualizamos a la última" el lunes por la mañana, actualizaste a una versión que no te protege. Este es el segundo release consecutivo en el que nuestro runbook de parches se paga solo: inventario de versiones el día del anuncio, staging el mismo día, producción en la ventana de 24 horas.
El desglose de los siete CVEs importa, porque la mitad no aplica a todo el mundo:
| Advisory | Severidad | Se activa cuando | Qué hacer | CVE-2026-94483 — SSRF en Image Optimization | High | Defines images.remotePatterns con URLs remotas permitidas | Parchear y auditar que la allow-list no apunte a rangos privados | CVE-2026-94543 — poisoning de caché SSG/ISR autoalojada | Medium | Tú mismo sirves la caché de páginas estáticas | Parchear y vaciar cachés tras el upgrade | CVE-2026-94484 — poisoning vía catch-all en la raíz | Medium | Tienes una página catch-all de nivel raíz con rutas SSG/ISR | Parchear; revisar las claves de caché compartida | Rutas de metadatos (opengraph-image) ignoran dynamicParams | Medium | App Router construido con webpack y rutas dinámicas excluidas de generateStaticParams | Parchear; con Turbopack no aplica | GHSA-h694-7cp9-m8p3 — fuga de caché entre params en 'use cache' anidadas | Medium | Usas funciones 'use cache' anidadas con params de nivel raíz | Parchear | CVE-2026-94544 — Draft Mode filtrado en respuestas normales | Medium | Habilitas Cache Components (o experimental.useCache) y sirves previews de Draft Mode | Parchear y revalidar previews | CVE-2026-94486 — endpoint MCP de next dev | Low | Ejecutas next dev con next >= 16.0.0 | Parchear a 16.3.8 y aplicar las reglas de exposición de abajo |
|---|
Fíjate en la última fila. Es la única con severidad Low, y es la única que trata el entorno de desarrollo como si fuera un producto con usuarios atacantes.
Qué puede hacer exactamente el endpoint MCP
Según el advisory GHSA-39w2-rjm5-chcv, el endpoint de MCP que expone next dev no verifica el origen de las peticiones. El ataque no necesita llegar al puerto desde la red: el desarrollador visita una web maligna, y esa web — desde el propio navegador de la víctima, contra localhost — habla con el endpoint y se lleva cuatro cosas concretas: la ubicación del proyecto en disco, fragmentos de código de los reportes de error, el inventario de rutas y los logs de desarrollo. El advisory marca affected >= 16.0.0 y patched 16.3.8, con severidad Low y CVSS 2.3.
En el modelo de amenaza clásico, "el desarrollador visita una web rara mientras tiene el dev server corriendo" suena a escenario menor. Y para 2019 lo era. El problema es quién pasa hoy las horas junto a next dev.
Por qué la calificación "Low" se queda corta
Tres señales de que el servidor de desarrollo ya no es un juguete local:
Los frameworks lo están construyendo como infraestructura para agentes. Astro 7, en su anuncio oficial, no solo añadió astro dev --background: detecta automáticamente cuándo está corriendo dentro de un agente de IA y activa el modo background sin flags, y activa JSON logging para que el agente pueda leer la salida. Es una decisión de producto deliberada: el dev server pasa a ser un sistema que habla con máquinas, no solo con humanos. Cuando un sistema habla con máquinas, sus endpoints se auditan como se auditan los de producción.
Los agentes ya viven en nuestro propio pipeline. Nosotros publicamos este blog con un pipeline asistido por agentes — cuatro crons que proponen, generan, validan y publican artículos bilingües — y la primera capa de nuestra arquitectura de guardrails es identidad con mínimo privilegio. Un endpoint del dev server sin verificación de origen es exactamente lo contrario: acceso amplio sin identidad que comprobar. En nuestro análisis de seguridad en vibe coding ya documentamos que el 45% del código generado por IA trae fallos del OWASP Top 10; el CVE de esta semana muestra que el riesgo no está solo en el código que el agente escribe, sino también en el proceso que el agente mantiene vivo.
La superficie de exposición real no es localhost. Porque nadie trabaja solo en localhost: los previews se comparten con clientes, los dev servers se tunelan con cloudflared o ngrok para una revisión rápida, y en algunos equipos el servidor se abre a la LAN para probar en un dispositivo. Cada una de esas decisiones convierte un endpoint "de desarrollo" en un endpoint alcanzable.
El modelo de exposición que aplicamos
| Ruta de exposición | Cómo alcanza el endpoint | Escenario real | Nuestra regla | A — Solo localhost | Cualquier pestaña abierta en el navegador del desarrollador puede llamar a localhost | El desarrollador navega a la vez que corre next dev | Parchear y usar un perfil de navegador dedicado para sesiones de desarrollo | B — Túnel o URL de preview compartida | El endpoint se sirve a quien tenga la URL | Túnel de cloudflared/ngrok para revisión con cliente | Nunca tunelar un dev server sin parchear; compartir un build o un preview de plataforma | C — Escuchando en 0.0.0.0 / LAN | Cualquier equipo de la red llega al puerto | Demo en la Wi-Fi de la oficina | Parchear primero; los dev servers con endpoints MCP se quedan en loopback |
|---|
La ruta A es la que la severidad "Low" da por descontada, y es justo la más común: el atacante no toca la red, viaja en el navegador de la víctima. La ruta B es la que más veo en agencias — el "te paso el link para que lo veas" — y es la que convierte un CVE de desarrollo en un incidente.
El checklist de verificación cabe en cinco líneas:
npx next info— ¿estás en 16.3.8 / 15.5.27? Si no, actualiza hoy; es unnpm install.ss -ltnp | grep -E '3000|3001'— ¿qué proceso escucha y sobre qué interfaz?- ¿Hay algún túnel (cloudflared, ngrok, frp) apuntando a ese puerto esta semana?
- ¿Tu config mezcla
images.remotePatterns, catch-all en la raíz o Cache Components? Cada una activa un advisory distinto de la tabla. - Después del upgrade: vaciar cachés de SSG/ISR y revalidar previews de Draft Mode. Parchear sin purgar solo mueve el problema.
Lo que esto no es
No es un "Next.js es inseguro". El proceso de Vercel — anuncio con 24 horas de antelación, advisories con CVE y GHSA, dos LTS parchadas en paralelo — es el estándar al que deberían aspirar todos los frameworks; lo escribimos en nuestro runbook de agosto y seguimos usándolo. Tampoco es motivo para apagar el dev server y trabajar contra producción: la misma disciplina de configuración que ya aplicamos a Astro aplica aquí — el entorno de desarrollo configura con los mismos criterios que producción, porque en 2026 la diferencia entre ambos es quién tiene la sesión abierta.
La señal de esta semana es otra: el endpoint que Vercel calificó como Low es el primero de su clase, no el último. A medida que los agentes se asienten en el ciclo de desarrollo, verás más advisories que afectan a next dev y no a next start. La pregunta útil no es si tu servidor de desarrollo estaba en la tabla de siete filas de esta semana — es si tendrías forma de saberlo en 24 horas si lo estuviera.
Preguntas Frecuentes
¿La vulnerabilidad del endpoint MCP de Next.js afecta a producción?
No. Según el advisory de Vercel, solo se ven afectadas las aplicaciones ejecutadas con `next dev`; las despliegues de producción no sirven ese endpoint. El alcance es next >= 16.0.0 y la solución llega en 16.3.8.
¿Cómo sé si mi proyecto está expuesto?
Tres comprobaciones: la versión instalada (`npx next info` o package.json — parche en 16.3.8 y 15.5.27), si ejecutas `next dev` habitualmente, y si algo expone ese servidor fuera de localhost (túneles de cloudflared/ngrok, bind a 0.0.0.0, o una IP de LAN). Si las tres respuestas son sí, actualiza hoy.
¿Cuál de las siete vulnerabilidades del 30 de septiembre me toca?
Depende de tu configuración: el SSRF de imagen solo si defines `images.remotePatterns`; el poisoning de caché solo si autoalojas SSG/ISR o tienes una catch-all en la raíz; la fuga de Draft Mode solo si habilitas Cache Components; y la del endpoint MCP siempre que ejecutes `next dev` con next 16.x. La tabla del artículo mapea cada advisory a la condición que lo activa.
