Parche incompleto en Next.js App Router: qué comprobar en 2026

Si tu empresa despliega Next.js App Router en producción, actualizar de versión tras un aviso de seguridad no basta para darse por parcheado. La vulnerabilidad crítica de middleware CVE-2025-29927 (marzo de 2025) seguía siendo explotable en despliegues self-hosted que no retiraban la cabecera x-middleware-subrequest en su proxy inverso, aunque el código ya llevara la versión corregida. Comprobar el número de versión es el primer paso, no el único paso.

La vulnerabilidad afectaba a cómo Next.js distinguía peticiones internas de peticiones externas dentro del sistema de middleware del App Router. Internamente, el framework usaba la cabecera x-middleware-subrequest para marcar que una petición ya había pasado por el middleware y no debía volver a ejecutarlo, evitando bucles infinitos en ciertos escenarios de reescritura. El problema es que nada impedía que un cliente externo añadiera esa misma cabecera a su propia petición HTTP. Al hacerlo, Next.js interpretaba la llamada como interna y saltaba directamente la ejecución del middleware, incluida cualquier comprobación de sesión, rol o redirección de login que vivera ahí dentro. En un patrón muy habitual del App Router —proteger rutas enteras con un único middleware.ts en la raíz del proyecto— eso equivalía a desactivar la autenticación con una sola cabecera falsificada.

En Vercel, la plataforma controla el borde de red y puede aplicar mitigaciones a nivel de edge sin que el cliente haga nada más que redeployar. En un despliegue self-hosted —Docker detrás de nginx, un VPS con PM2, un clúster Kubernetes propio, que es el escenario típico de una PYME tecnológica española que gestiona su propia infraestructura— esa capa de filtrado de cabeceras no existe salvo que alguien la escriba. Muchos equipos hicieron npm update, vieron que el changelog mencionaba la vulnerabilidad como corregida y cerraron el ticket sin tocar la configuración del proxy inverso. El parche de versión elimina la confianza ciega en esa cabecera dentro del propio Next.js, pero no impide que quede expuesta si el reverse proxy la deja pasar sin filtrar, algo relevante también de cara a futuras variantes de la misma clase de bug basada en spoofing de cabeceras internas.

• Versiones con el fix aplicado: 12.3.5, 13.5.9, 14.2.25 y 15.2.3 (rama correspondiente según tu proyecto)
• Comprobar que el proxy inverso (nginx, Traefik, API Gateway) descarta cabeceras x-middleware-subrequest procedentes del cliente
• Revisar si el middleware.ts realiza comprobación real de autorización o solo verifica la existencia de una cookie
• Confirmar que no queden instancias antiguas en caché de CDN sirviendo el bundle previo al parche

Más allá del CVE puntual, esta vulnerabilidad expuso un patrón arquitectónico frágil que sigue vivo en muchos proyectos aunque estén al día de versión. La documentación del App Router presenta el middleware como el lugar natural para proteger rutas, y muchos equipos lo interpretan como suficiente: si el middleware redirige a login cuando no hay sesión, el resto de la aplicación se considera protegido por herencia. El problema es que el middleware corre en el runtime Edge, con acceso limitado a APIs de Node y normalmente sin conexión directa a base de datos, así que en la práctica suele limitarse a comprobar que existe una cookie o un token, no a verificar permisos reales sobre el recurso solicitado. Cualquier fallo futuro de la misma familia —bypass de ejecución del middleware, cache poisoning, cabeceras mal gestionadas por un CDN intermedio— vuelve a dejar la aplicación entera sin protección si esa es la única barrera.

Route Handlers y Server Components deben revalidar sesión, no fiarse del middleware

La recomendación de defensa en profundidad que siguió al incidente es sencilla de enunciar y tediosa de aplicar bien: cada Route Handler, Server Action y Server Component que toque datos sensibles debe volver a comprobar sesión y permisos por su cuenta, sin asumir que si la petición llegó hasta ahí es porque el middleware ya la validó. En React Server Components esto es especialmente relevante porque el fetch de datos ocurre en el propio servidor, dentro del componente, lo que significa que si la query de base de datos no filtra por el usuario autenticado y su rol, un bypass del middleware expone directamente los datos sin ninguna capa intermedia que lo impida. Tratar el middleware como una optimización de UX (evitar que un usuario sin sesión vea una pantalla de carga antes de ser redirigido) y no como el único control de acceso reduce drásticamente el radio de impacto de cualquier bypass futuro.

El matcher que se olvida de las rutas nuevas del App Router

Hay un segundo problema, más silencioso y más habitual, que no depende de ningún CVE: el array matcher del middleware. Por defecto muchos proyectos lo dejan amplio, pero en cuanto alguien lo optimiza para evitar ejecutar el middleware en assets estáticos o rutas públicas, empieza a limitarlo a patrones concretos como /dashboard/:path*. El problema aparece meses después, cuando el equipo añade un nuevo route group anidado —por ejemplo /dashboard/(admin)/configuracion— y nadie actualiza el matcher para incluirlo. La ruta nueva queda técnicamente fuera del alcance del middleware sin que ningún test la detecte, porque desde el punto de vista funcional la aplicación sigue funcionando perfectamente; simplemente ya no está protegida. Ninguna actualización de versión de Next.js revisa esto por ti: es responsabilidad exclusiva de quien mantiene el proyecto, y es el tipo de gap que solo aparece al leer el código, no al ejecutar npm audit.

• Confirmar la versión exacta de Next.js desplegada en producción y compararla con la última parcheada de su rama
• Revisar la configuración del proxy inverso o CDN propio para descartar cabeceras x-middleware-* entrantes del cliente
• Auditar qué comprueba realmente middleware.ts: existencia de cookie, validez de token, o rol y permisos concretos
• Repetir la comprobación de autorización dentro de cada Server Component, Route Handler y Server Action que acceda a datos sensibles
• Revisar el array matcher tras cada route group o ruta nueva añadida al App Router
• Probar manualmente el envío de la cabecera x-middleware-subrequest contra rutas protegidas para confirmar que el bypass ya no funciona
• Revisar logs de acceso previos a la actualización buscando cabeceras x-middleware-* sospechosas desde IPs externas

No toda empresa con Next.js en producción necesita contratar una auditoría externa por este incidente, y es honesto decirlo aunque no nos beneficie. Si tu proyecto está desplegado en Vercel con configuración por defecto, tu middleware solo hace redirecciones simples sin lógica de autorización compleja, y ya has aplicado la actualización de versión, una revisión interna de medio día siguiendo la checklist anterior suele ser suficiente. Donde sí recomendamos escalar a una revisión más profunda es cuando el middleware concentra lógica de negocio real —comprobación de roles, feature flags de pago, límites de uso—, cuando la infraestructura es self-hosted con proxies propios, o cuando la aplicación maneja datos regulados por RGPD o sector financiero, porque ahí el coste de un fallo silencioso de matcher o de una cabecera mal filtrada deja de ser una molestia y pasa a ser un incidente reportable.