Next.js acaba de parchear 13 avisos de seguridad. Los equipos con alojamiento propio tienen el mayor trabajo.

El 7 de mayo, Vercel lanzó una actualización de seguridad coordinada que cubre 13 avisos en Next.js y React Server Components. El paquete incluye problemas de alta gravedad como denegación de servicio, falsificación de solicitudes del lado del servidor, envenenamiento de caché y varios fallos de bypass de middleware que afectan a App Router. Si su equipo ejecuta Next.js con alojamiento propio en Node, usted tiene el mayor trabajo por cubrir.

Las correcciones llegan en 15.5.18 y 16.2.6. Los usuarios de React que trabajan con react-server-dom deben actualizar a 19.0.6, 19.1.7 o 19.2.6 según la versión que utilicen. Las versiones 13.x y 14.x no recibirán parches, por lo que quienes aún las utilicen deben planificar una actualización en lugar de esperar una solución retroactiva.

Qué contiene realmente el paquete

El CVE principal que citan la mayoría de los medios es CVE-2026-23870, una vulnerabilidad DoS de alta gravedad en la deserialización del protocolo React Flight. Una solicitud HTTP especialmente diseñada hacia cualquier función de servidor de App Router puede saturar un núcleo de CPU. Es grave, pero tiene una forma de error conocida, del tipo que un WAF o limitador de velocidad puede mitigar.

La categoría que merece más atención es el conjunto de bypasses de middleware. Los avisos describen variantes en las que las URLs .rsc y las URLs de prefetch de segmento resuelven a la misma página que una solicitud normal, pero omiten las reglas del matcher de middleware. En otras palabras: si su middleware.ts es lo único que separa una solicitud no autenticada de una página protegida, un atacante puede solicitar el mismo contenido a través de un transporte diferente y acceder sin restricciones. Hay una variante relacionada con Pages Router vinculada al manejo de locales i18n, además de un aviso adicional para la ruta de código de Turbopack porque la corrección original no la cubría.

Los avisos restantes cubren SSRF mediante solicitudes de actualización de WebSocket en Node con alojamiento propio (las aplicaciones alojadas en Vercel no se ven afectadas), DoS en la API de optimización de imágenes, XSS y envenenamiento de caché de respuestas RSC.

Por qué el «middleware como autenticación» sigue afectando a los equipos

En nuestros compromisos de pentesting, este es uno de los patrones que verificamos primero cuando vemos Next.js en el alcance. El patrón se repite: un único middleware.ts verifica la cookie de sesión, redirige al inicio de sesión si no está presente, y el equipo considera protegidas todas las rutas que hay debajo. Parece limpio. Se lee bien en las PRs. Y suele tener un hueco de variante de transporte que alguien acabará encontrando.

El middleware en Next.js es una cuestión de enrutamiento. Se ejecuta de manera temprana, tiene APIs limitadas y ha tenido históricamente particularidades en cómo los matchers se aplican a las formas de solicitud internas (payloads RSC, prefetches, segmentos dinámicos, rutas con prefijo de locale). Cada una de esas particularidades ha surgido en algún momento como una clase de CVE. El lote de esta semana es el último recordatorio.

Cuando construimos aplicaciones cloud-native con App Router, tratamos el middleware como un filtro de ruta rápida y colocamos las verificaciones de autorización reales en el manejador de ruta, la acción del servidor o el propio componente del servidor. El valor de la cookie se convierte en la entrada, no en el veredicto. Esa verificación adicional tiene un coste casi nulo y elimina toda una familia de riesgos de bypass.

Qué hacer esta semana

Una lista breve:

1. Actualice next a 15.5.18 o 16.2.6. Si publica en Pages Router con i18n a través del adaptador OpenNext, actualice también a 5.15.11.
2. Si depende directamente de react-server-dom-*, ajústelo a la línea de parches 19.x que está utilizando (19.0.6, 19.1.7 o 19.2.6).
3. Planifique la migración desde 13.x o 14.x. Esas ramas no recibirán estas correcciones.
4. Audite su middleware.ts. Si una ruta está protegida únicamente por middleware, añada una verificación de autenticación del lado del servidor dentro del manejador de ruta, la acción del servidor o el layout. No omita este paso solo porque haya actualizado.
5. Para las implementaciones de Node con alojamiento propio, revise los registros de edge o proxy en busca de solicitudes .rsc inusuales, actualizaciones de WebSocket a orígenes inesperados y picos de tráfico en la API de optimización de imágenes. Los problemas de SSRF y DoS aparecerán primero en entornos con alojamiento propio.

Una nota sobre alojamiento propio frente a plataforma

Varios de estos problemas están explícitamente limitados al Node con alojamiento propio. Vercel afirma que los proyectos alojados contaban con reglas WAF antes del parche. Netlify indica que algunos de los avisos no se aplican a su modelo serverless en absoluto. Esa brecha merece reflexión a la hora de decidir dónde ejecutar Next.js.

Desde nuestro trabajo de desarrollo cloud-native, hemos visto a muchos equipos optar por el alojamiento propio por razones de coste o cumplimiento normativo (especialmente clientes empresariales suizos), y es una decisión válida. Sin embargo, usted asume una mayor responsabilidad en la seguridad del entorno de ejecución, y el ritmo de aplicación de parches se convierte en parte del presupuesto operativo, no en una tarea trimestral secundaria.

Si mantener un stack de Next.js con alojamiento propio reforzado y parcheado según un calendario real le resulta familiar, hablemos. Realizamos este trabajo en proyectos web y móviles y revisiones de seguridad, y la respuesta rara vez es «más middleware».