El 23 de marzo de 2025 fue publicada una nueva vulnerabilidad crítica en Next.js identificada como CVE-2025-29927, relacionada con el mecanismo de Middleware en entornos autohospedados. Esta falla de seguridad permite a un atacante eludir la ejecución del Middleware mediante la manipulación del encabezado interno x-middleware-subrequest, comprometiendo así la integridad de las validaciones que dependen exclusivamente de esta capa.
Ante esta situación, muchas empresas que ya utilizan autenticación basada en tokens JWT se preguntan:
¿Estoy realmente en riesgo?
¿Qué es la vulnerabilidad CVE-2025-29927?
Next.js utiliza internamente el encabezado x-middleware-subrequest para evitar bucles infinitos en peticiones que activan Middleware. La vulnerabilidad descubierta permite a un atacante malicioso incluir este encabezado manualmente, con lo cual es posible evitar que se ejecute el Middleware configurado, eludiendo así cualquier validación o lógica de seguridad implementada exclusivamente en esta capa.
Esto representa un riesgo considerable para aplicaciones que delegan tareas de autenticación, autorización o validación directamente al Middleware sin mecanismos adicionales del lado del servidor.
¿Quiénes están afectados?
Aplicaciones afectadas:
- Aquellas autohospedadas usando next start.
- Que emplean «output»: «standalone».
- Que utilizan Middleware para proteger rutas o gestionar sesiones de usuario.
Aplicaciones no afectadas:
- Desplegadas en plataformas como Vercel o Netlify.
- Exportadas como contenido estático con next export.
- Que no dependen del Middleware para validaciones críticas.
¿Qué sucede si ya usas tokens JWT y validas en el backend?
En los proyectos que implementan autenticación robusta con tokens JWT firmados por el backend, el impacto de esta vulnerabilidad puede ser mínimo, siempre que se cumplan las siguientes condiciones:
- El token se genera y firma en el backend.
- Cada petición sensible es validada directamente en el servidor, sin depender únicamente del Middleware.
- El Middleware se utiliza solo para mejorar la experiencia de usuario, por ejemplo, con redirecciones o cargas condicionales.
En estos casos, la seguridad de tu aplicación no se ve comprometida.
Aunque el Middleware pueda ser omitido, el acceso a información sensible sigue protegido por las validaciones estrictas del backend, garantizando la integridad de tu sistema.
¿Cuándo representa un riesgo real?
La vulnerabilidad se vuelve crítica si:
- El Middleware es el único responsable de validar autenticación o permisos de acceso.
- Se permiten accesos a recursos sensibles sin una verificación adicional en la API del backend.
- El cliente accede directamente a datos sin un control robusto del lado del servidor.
En estos escenarios, un atacante podría modificar manualmente el encabezado x-middleware-subrequest para evadir la lógica de seguridad y acceder a rutas protegidas sin autorización.
Recomendaciones para desarrolladores y equipos técnicos
- Actualizar inmediatamente Next.js a una versión corregida:
- v15.x → 15.2.3
- v14.x → 14.2.25
- v13.x → 13.5.9
- v12.x → 12.3.5
- Nunca delegues completamente la seguridad a la capa de Middleware. Toda lógica sensible debe ser verificada en el backend.
- Si no puedes actualizar de inmediato, bloquea manualmente solicitudes externas que contengan el encabezado x-middleware-subrequest.
- Revisa tus flujos de autenticación y asegúrate de aplicar una arquitectura de defensa en profundidad.
Lecciones para arquitecturas seguras
Este incidente subraya un principio clave en desarrollo seguro:
La autenticación y la autorización deben implementarse y validarse siempre en el servidor.
Nunca deben depender de capas que puedan ser manipuladas desde el cliente.
El uso de tokens firmados, el control del ciclo de vida del token, y la validación en backend siguen siendo las mejores prácticas para proteger tus sistemas ante vulnerabilidades de este tipo.
¿Cómo enfrentamos esta vulnerabilidad en Dofleini?
En Dofleini Software, como parte de nuestro compromiso con la seguridad y la calidad de los productos que desarrollamos, realizamos un análisis exhaustivo en cuanto se dio a conocer esta vulnerabilidad. Tras revisar todos nuestros entornos y flujos de autenticación, confirmamos que ninguna de nuestras aplicaciones se vio afectada, gracias a la arquitectura segura que implementamos desde el diseño de cada solución.
En todos nuestros proyectos, las peticiones que involucran datos sensibles o requieren acceso autorizado son validadas directamente en el backend, mediante el uso de tokens firmados (JWT) generados y verificados exclusivamente por el servidor. El Middleware se emplea únicamente para funciones auxiliares que mejoran la experiencia del usuario, como redirecciones o gestión de estado visual, pero nunca se confía en él como único mecanismo de seguridad.
A pesar de no estar directamente expuestos, aplicamos las actualizaciones recomendadas en todas nuestras aplicaciones autohospedadas como parte de nuestras buenas prácticas de ciberseguridad proactiva, asegurando una protección integral frente a posibles vectores de ataque.
Recursos y enlaces de interés