CVE-2025-29927 en Next.js: por qué el middleware no debe ser tu única barrera de acceso

Publicado el 2026-10-27 por frfrand

El bypass de middleware en Next.js explicado con escenarios reales, alcance por hosting, parches y recomendaciones de autorización.

El escenario: ocultar una página no significa proteger sus datos

Supongamos que creaste un panel privado con Next.js. El middleware comprueba si hay sesión y, si no la encuentra, redirige al login. Parece suficiente, pero CVE-2025-29927 dejó una lección importante: una falla en el tratamiento de cierta señal interna del framework podía hacer que se omitiera la ejecución del middleware. Si toda la seguridad dependía de ese único paso, algunas rutas podían quedar accesibles indebidamente.

¿Qué es middleware en Next.js?

Es código que puede intervenir antes del enrutamiento para modificar, redirigir o bloquear peticiones. Sirve para muchas tareas, incluida una comprobación inicial de sesión. Pero una validación de acceso sensible también debe ejecutarse donde se entregan los datos o se realiza la operación, no solamente antes de llegar a la página.

¿Quién descubrió la vulnerabilidad y cómo se reportó?

Next.js acredita a los investigadores Rachid Allam (zhero) y Yassir Alam (inzo_). El informe privado inicial llegó el 27 de febrero de 2025. En su análisis posterior, el proyecto detalló retrasos y mejoras de coordinación antes de publicar los parches y la CVE en marzo. Es un caso útil para entender la divulgación responsable y por qué el proceso de respuesta también forma parte de la seguridad.

¿Cómo podía explotarse?

Next.js utilizaba un encabezado interno para identificar solicitudes que no debían volver a pasar por ciertas partes del middleware. En implementaciones vulnerables, una petición externa manipulada podía aprovechar ese mecanismo e influir en la ejecución del control. No significa que todas las aplicaciones Next.js expusieran datos: el efecto práctico dependía de si el middleware era la única barrera de autorización.

¿Qué instalaciones estaban expuestas?

El análisis oficial confirmó riesgo en determinadas aplicaciones autohospedadas con next start y output: 'standalone'. Descartó las exportaciones estáticas sin middleware. También indicó que la arquitectura de despliegue de Vercel, Netlify y Cloudflare Workers evaluada entonces no sufría ese bypass. Por eso, al estudiar una CVE de Next.js, el modo de despliegue es tan importante como la versión.

¿Qué versiones recibieron el parche?

El proyecto publicó correcciones para 14.2.25, 15.2.3, y después versiones retroportadas 13.5.9 y 12.3.5 en marzo de 2025. Estas son las primeras correcciones históricas: para un proyecto nuevo o una actualización en 2026, buscá una versión de mantenimiento vigente.

¿Qué hago para proteger una app?

Actualizá Next.js y verificá el artefacto desplegado; revisá qué endpoints confían exclusivamente en middleware; comprobá la autorización también en handlers, server actions y acceso a datos; bloqueá cabeceras internas no confiables en el borde cuando el aviso lo recomiende y la actualización no sea inmediata. Los controles deben decidir sobre la identidad y los permisos de cada operación sensible.

¿Cómo sé si alguien aprovechó el problema?

Contrastá accesos a rutas protegidas, patrones inusuales en logs de proxy, operaciones realizadas por usuarios y ausencia de comprobaciones de autorización. Un acceso a un recurso no equivale necesariamente a filtración, pero puede justificar revisión de incidentes. Si hubo exposición, rotá credenciales y notificá según las obligaciones aplicables.

Preguntas frecuentes

¿La aplicación se salva si usa JWT? Un token no corrige un flujo que deja saltar el único control de autorización.

¿El proveedor de VPS puede arreglarlo por mí? El parche del framework y las decisiones de autorización siguen siendo responsabilidad del código y su despliegue, según el servicio contratado.

¿Debo dejar de usar middleware? No: usalo como una capa más, no como frontera única.

Fuentes: Postmortem oficial de Next.js · Registro CVE.

¿Dónde seguir alertas CVE y recibir orientación?

En ArduMaker CVE y soporte publicamos actualizaciones y centralizamos consultas sobre vulnerabilidades, comenzando por WordPress y sus tecnologías relacionadas. Si tu caso involucra otro runtime o una base de datos, especificá componente, versión, sistema operativo y exposición del servicio para contextualizarlo. El aviso de una CVE no prueba que tu servidor esté comprometido: la evaluación requiere inventario, configuración y evidencia.

Nota editorial — octubre de 2026: estas versiones corregidas son los hitos del aviso original. Al actualizar hoy, elegí una rama con soporte vigente y verificá el comunicado actual del fabricante.

Ejemplo práctico: dos barreras para una ruta de administración

Situación: una app Next.js oculta /admin mediante middleware, pero el handler que devuelve facturas no comprueba los permisos del usuario. CVE-2025-29927 mostró por qué depender de una sola barrera es un riesgo.

En un Route Handler, implementá otra validación independiente:

// Ejemplo ilustrativo: getCurrentUser debe implementarse
// con tu sistema real de sesiones.
export async function GET(request) {
  const user = await getCurrentUser(request);
  if (!user || !user.isAdmin) {
    return new Response("Acceso denegado", { status: 403 });
  }
  return Response.json(await cargarFacturasAutorizadas(user));
}

Antes: «si pasó por middleware, entonces puede ver todo». Después: middleware para redirección o primera comprobación, más autorización en la ruta, server action y capa de datos según corresponda.

Prueba funcional segura: iniciá sesión con una cuenta sin permisos de administrador y pedí el endpoint normalmente. El servidor debe devolver 403 y no entregar los datos. Además, actualizá Next.js al parche correspondiente y verificá el modo de despliegue.