Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Si estás utilizando Next.js en producción, entonces —según las estadísticas— es muy probable que hayas tenido ese momento. Quizás sea durante una auditoría de seguridad. Quizás sea un compañero que te reenvía una notificación de CVE con un asunto que empieza por «Atención…». O quizás sea el escáner de dependencias que te avisa de una versión que llevas utilizando desde hace dos años.
Ya sabes a qué momento me refiero: ese en el que te enteras de que un componente de código abierto que utilizas tiene, de repente, un CVE de gravedad crítica.
Next.js está en todas partes. Es el marco de trabajo que sustenta desde los MVP de startups incipientes hasta la infraestructura de producción de Walmart, TikTok, Nike y Uber. Si tu equipo desarrolla aplicaciones React para la web, es muy probable que Next.js ya forme parte de tu pila tecnológica y, lo que es más probable aún, que esté ejecutando una versión que ya ha llegado al final de su ciclo de vida o que lo hará pronto.
Cuando el «fin de vida útil» de Next.js empieza a aparecer en tus paneles de seguridad y en tus informes de auditoría, es fácil que te invada la ansiedad. De repente, el marco de trabajo que ha prestado un servicio fiable a tus usuarios empieza a parecer una bomba de relojería. Pero no tiene por qué ser así. Analicemos qué significa realmente el fin de vida útil de Next.js para tus aplicaciones, cuáles son los riesgos reales y, lo que es más importante, qué puedes hacer de forma realista al respecto sin trastocar tu hoja de ruta.
Principales conclusiones
- Next.js incluye un extenso árbol de dependencias, entre las que se encuentran React, styled-jsx, postcss, @swc/helpers y muchas otras, lo que significa que el riesgo de que Next.js deje de recibir soporte técnico se extiende mucho más allá del propio marco de trabajo, abarcando todos los paquetes transitivos que este incorpora.
- Las migraciones precipitadas entre versiones principales de Next.js rompen los supuestos sobre el enrutamiento, la representación y las API, lo que provoca regresiones, una sobrecarga en el servicio de asistencia y unos costes que superan con creces el precio de la asistencia ampliada.
- TuxCare ELS ofrece cobertura continua de parches de seguridad para las versiones de Next.js que han llegado al final de su ciclo de vida, lo que permite a tu equipo disponer del tiempo necesario para planificar una actualización adecuada en lugar de tener que reaccionar bajo presión.
Cómo funcionan realmente las versiones de Next.js
Next.js sigue un modelo estructurado de LTS (soporte a largo plazo) que Vercel (la empresa que creó y mantiene Next.js) formalizó en 2024. Comprender esta cadencia es clave para saber exactamente cuándo una versión se convierte en un lastre.
Cuando se lanza una nueva versión principal, pasa inmediatamente a estado LTS activo . Durante esta fase, la versión recibe nuevas funciones, correcciones de errores periódicas, mejoras de rendimiento y parches de seguridad. Esta es la fase en la que te conviene estar.
Una vez que se lance la próxima versión principal, la anterior pasará a LTS de mantenimiento. En esta fase, solo se proporcionan correcciones de errores críticos y actualizaciones de seguridad esenciales, sin nuevas funciones. El mantenimiento LTS tiene una duración de dos años a partir de la fecha de lanzamiento inicial de la versión.
Una vez transcurrido ese plazo de dos años, la versión deja de recibir soporte. No habrá más parches. No habrá más correcciones. El fin de la vida útil está en pleno apogeo.
A continuación se muestra el panorama actual de las versiones, según la Política oficial de compatibilidad de Next.js:
- Next.js 16.x (LTS activa) lanzada el 21 de octubre de 2025; actualmente compatible con funciones, correcciones y parches de seguridad
- Next.js 15.x (LTS de mantenimiento) lanzada el 21 de octubre de 2024; recibirá correcciones críticas y actualizaciones de seguridad hasta octubre de 2026
- Next.js 14.x (fin de vida útil ~ 26 de octubre de 2025) lanzado el 26 de octubre de 2023; ya no recibe parches ni actualizaciones de seguridad
- Next.js 13.x y versiones anteriores no son compatibles; las fechas de fin de vida útil van desde 2024 hasta 2016
Desde 2020 se han lanzado nuevas versiones principales cada mes de octubre. Se trata de un ritmo predecible, pero también significa que los equipos que utilizan Next.js 13 o 14 —ambas versiones muy populares en entornos de producción— ya se encuentran en la fase de fin de vida útil (EOL) de Next.js y han superado el límite de seguridad.
Qué significa realmente el fin de la vida útil de Next.js para tu aplicación
Tu aplicación sigue en funcionamiento. Las páginas se cargan. Las rutas de la API responden. Entonces, ¿qué cambia exactamente cuando una versión llega al final de su vida útil (EOL) en Next.js?
A simple vista, todo parece estar bien. El riesgo reside en lo que no se ve: cualquier vulnerabilidad que se descubra después de la fecha de fin de vida útil (EOL) quedará sin parchear. Ni Vercel ni el equipo de Next.js publicarán una corrección. La comunidad tampoco adaptará ninguna solución. Tu versión dejará de ser más segura, mientras que el panorama de amenazas sigue evolucionando.
Y para un marco que gestiona la representación del lado del servidor, las rutas de la API, el middleware de autenticación y la obtención de datos, todo ello en un único código base, la superficie de exposición a riesgos de seguridad es considerable.
Un historial de vulnerabilidades CVE que llama la atención
Next.js tiene un historial bien documentado de vulnerabilidades de seguridad importantes, y este caso ilustra perfectamente por qué es peligroso utilizar una versión que ya no recibe soporte.
El que más titulares acaparó fue CVE-2025-29927 (CVSS 9.1, Crítico), una vulnerabilidad de elusión de autorización del middleware revelada en marzo de 2025. Esta vulnerabilidad, que afectaba a las versiones 11.1.4 a 15.2.2 de Next.js, permitía a los atacantes saltarse por completo la ejecución del middleware, incluidas las comprobaciones de autenticación y autorización, mediante la manipulación de un único encabezado HTTP interno, x-middleware-subrequest. Un atacante podía obtener acceso a rutas de administración protegidas, eludir los encabezados de la Política de Seguridad de Contenidos y, en determinadas configuraciones, contaminar las cachés de CDN, todo ello sin necesidad de credenciales. Dado lo habitual que es el uso del middleware de Next.js como capa de autorización principal, el impacto práctico fue grave.
Posteriormente, en diciembre de 2025, se detectó un conjunto de vulnerabilidades críticas en el protocolo React Server Components (RSC) que afectaban directamente a las aplicaciones Next.js que utilizaban el App Router. El problema principal, CVE-2025-55182 (CVSS 10.0, la puntuación máxima de gravedad, según el informante), permitía a un atacante no autenticado ejecutar código de forma remota simplemente enviando una solicitud HTTP manipulada a cualquier punto final del App Router. No se requería autenticación. No se necesitaba ninguna configuración especial. Un nuevo create-next-app con la configuración predeterminada era inmediatamente vulnerable. Los proveedores de seguridad observaron una explotación activa en la red, con atacantes que utilizaban la vulnerabilidad para robar credenciales de la nube e implementar mineros de criptomonedas.
Las investigaciones posteriores a la corrección inicial sacaron a la luz dos vulnerabilidades adicionales: CVE-2025-55184 (CVSS 7,5, denegación de servicio mediante bucle infinito. Nota: la corrección inicial era incompleta, por lo que se requirió una segunda actualización bajo CVE-2025-67779) y CVE-2025-55183 (CVSS 5.3, exposición del código fuente a través de Server Functions), ambas afectando a React 19 y a los marcos que lo utilizan, incluidas las versiones 13.x a 16.x de Next.js.
El patrón es constante: las vulnerabilidades de Next.js suelen ser de alta gravedad cuando se detectan, ya que el marco de trabajo opera en la intersección entre la ejecución del servidor, la autenticación y el enrutamiento orientado al usuario. En una versión fuera de soporte, cada una de estas vulnerabilidades se convierte en una exposición permanente sin parchear.
Más allá del riesgo directo para la seguridad, los marcos de cumplimiento normativo son cada vez más claros en lo que respecta al software sin soporte técnico. La norma PCI DSS exige que las vulnerabilidades críticas se corrijan en un plazo de 30 días. Los auditores de SOC 2 investigan específicamente la presencia de software al final de su ciclo de vida (EOL) en entornos de producción. El uso de versiones de Next.js que han llegado al final de su ciclo de vida genera problemas de documentación que pueden retrasar las certificaciones y los contratos con los clientes.
El riesgo oculto: todo tu árbol de dependencias
Cuando los equipos piensan en la seguridad de Next.js, suelen centrarse en el propio marco, el enrutamiento, la representación y la capa de API. Pero Next.js no funciona de forma aislada.
Una instalación estándar de Next.js incluye un amplio árbol de dependencias. Las dependencias directas del marco de trabajo incluyen paquetes como @next/env, styled-jsx, postcss, @swc/helpers, caniuse-lite, múltiples específicos de plataforma @next/swc-* , ws, semver, undici, y más —y eso sin contar con React y su propia cadena de dependencias. Cada uno de esos paquetes conlleva sus propias dependencias transitivas, y cada una de ellas es una superficie de vulnerabilidad en potencia.
El grupo de vulnerabilidades CVE-2025-55182 dejó muy claro el riesgo que supone esta cadena de dependencias. La vulnerabilidad se originó en paquetes de React de nivel superior (concretamente react-server-dom-webpack y los paquetes RSC relacionados), y Next.js heredó el fallo directamente porque depende de esos paquetes. Cuando un componente del árbol de dependencias se ve comprometido, todo lo que hay más abajo se ve afectado, y en una versión de Next.js al final de su vida útil (EOL), no hay ningún parche de los paquetes de origen que se pueda aplicar.
Esto es lo que hace que el fin de vida útil (EOL) de Next.js sea realmente complejo. Aunque el código de tu aplicación sea limpio, todo tu árbol de dependencias puede ser vulnerable a ataques, y en una versión EOL, npm audit no mostrará soluciones porque no hay parches que recomendar.
Tus opciones cuando llegue el fin de la vida útil de Next.js
Vale, tu versión de Next.js ha llegado al final de su ciclo de vida o está a punto de hacerlo. ¿Qué opciones realistas tienes para seguir adelante?
Dos de ellas implican una complejidad, un coste y un riesgo considerables. La tercera, el soporte ampliado, es la opción que realmente resuelve el problema sin causar interrupciones, y es la que la mayoría de los equipos desearían haber descubierto antes.
Opción 1: Actualizar a la siguiente versión principal
Esta es la respuesta «oficial». Actualiza a la última versión compatible de Next.js, instala los parches de seguridad más recientes y mantente dentro de la ruta de compatibilidad. En principio, esto es totalmente correcto.
Next.js 15 y 16 son, sin duda, mejores frameworks. El App Router está más maduro. Los componentes de servidor de React son más estables. Turbopack es el empaquetador predeterminado. Las API asíncronas para cookies y encabezados simplifican los patrones habituales. El comportamiento del almacenamiento en caché es más predecible. Si estás empezando desde cero, no hay razón para no utilizar la última versión.
Sin embargo, actualizar una aplicación de producción ya existente, especialmente una que utilice una versión de Next.js que haya llegado al final de su ciclo de vida (EOL), como la 13 o la 14, es un proyecto totalmente distinto. Las actualizaciones a versiones principales de Next.js no son simples sustituciones. Implican cambios que rompen la compatibilidad en el enrutamiento, la representación, la obtención de datos y el manejo de API. El App Router y el Pages Router coexisten, pero son modelos arquitectónicos fundamentalmente diferentes. La migración entre ellos es una reescritura, no una actualización. Las API asíncronas de React requieren adaptar todos los componentes que utilizan cookies, encabezados o parámetros. Los valores predeterminados de almacenamiento en caché cambiaron significativamente entre la versión 14 y la 15, rompiendo supuestos integrados en los patrones de obtención de datos en todo el código base.
En el caso de una aplicación pequeña, bien probada y con buena documentación, esto podría ser factible. Sin embargo, si se trata de una gran aplicación de producción con años de patrones acumulados, una lógica de middleware extensa y estrategias complejas de obtención de datos, te espera meses de trabajo minucioso, no semanas.
Opción 2: Migración a marcos alternativos
Algunos equipos, ante la noticia del fin de la vida útil de Next.js, llegan a la conclusión de que es el momento de replantearse por completo su elección de marco de trabajo.
Ya sea con Remix (ahora React Router v7), Astro, SvelteKit, Nuxt para equipos de Vue, o incluso volviendo a una configuración más sencilla de React con Vite, existen alternativas reales que vale la pena tener en cuenta. Cada una tiene sus puntos fuertes. La arquitectura de «islas» de Astro resulta muy atractiva para sitios web con gran cantidad de contenido. El enfoque de Remix respecto a la carga de datos y las mutaciones es elegante. Vale la pena considerar seriamente SvelteKit si tu equipo está abierto a un modelo de componentes diferente.
Pero las migraciones de marcos de trabajo son costosas. No se trata simplemente de cambiar un archivo de configuración; hay que reescribir cada página y cada componente utilizando el lenguaje propio del marco de destino, sustituir las API específicas de Next.js (optimización de imágenes, enrutamiento, acciones de servidor), reevaluar toda la infraestructura de implementación, volver a formar al equipo y reconstruir el conocimiento institucional en torno a un nuevo ecosistema. Los beneficios a largo plazo pueden merecer la pena, pero el coste y el plazo de la transición se subestiman sistemáticamente. Y durante toda la migración, tu aplicación Next.js EOL existente sigue funcionando en producción, acumulando vulnerabilidades sin parchear.
Opción 3: Asistencia técnica ampliada de terceros
Esta es la opción que muchos equipos desconocen: el soporte de seguridad ampliado que ofrecen empresas especializadas en garantizar la seguridad del software al final de su ciclo de vida.
TuxCare ofrece soporte técnico de por vida para las versiones de Next.js que han llegado al final de su ciclo de vida. En lugar de forzar una migración para la que tu equipo no está preparado, o dejar tu aplicación desprotegida mientras la planificas, puedes seguir utilizando tu versión actual de Next.js, pero con cobertura continua de parches de seguridad.
Te ganas tiempo y control. Tiempo para planificar una actualización adecuada según tus propios términos, con las pruebas pertinentes, la documentación necesaria y los recursos adecuados. Control sobre tu calendario de actualizaciones, en lugar de verte obligado a actuar por el plazo de una auditoría de seguridad o por la publicación de un CVE que te deja sin otra opción.
El verdadero coste de precipitarse al actualizar Next.js
Hablemos de lo que ocurre realmente cuando los equipos migran precipitadamente una aplicación de Next.js que ha llegado al final de su vida útil porque las alertas han alcanzado finalmente un nivel crítico en el panel de seguridad.
Actualizar a una nueva versión principal de Next.js implica adaptar el código en todas las páginas, componentes y rutas de la API; verificar la compatibilidad de todas las bibliotecas de la pila; adaptar el conjunto de herramientas para el proceso de compilación y despliegue; y asumir una carga de trabajo de pruebas que aumenta a medida que crece la complejidad de la aplicación. Ese trabajo no desaparece por el hecho de que la adaptación sea urgente.
Cuando esa actualización se ve obligada a ajustarse a un plazo poco realista, es inevitable que surjan problemas:
- Aumento de la carga de asistencia técnica: Empiezan a aparecer en producción pequeñas regresiones que no se detectaron durante las pruebas. El cambio en el comportamiento del almacenamiento en caché sirve datos obsoletos de forma silenciosa. Las modificaciones en las reglas de enrutamiento interrumpen los flujos de navegación. La cola de asistencia se llena de incidencias que se remontan a la migración.
- Inestabilidad del sistema: Un cambio en el comportamiento de una acción del servidor interrumpe un flujo de pago crítico. Una suposición modificada sobre la API asíncrona provoca fallos intermitentes en la autenticación. Estos son los problemas que generan alertas a las 3 de la madrugada, incumplimientos del SLA y partes interesadas muy descontentas.
- Acumulación de deuda técnica: En el afán por cumplir con los requisitos, se toman atajos. Se añaden soluciones de compatibilidad. «Ya lo arreglaremos más adelante» se convierte en la norma. Seis meses después de la migración, estás utilizando una versión técnicamente actualizada de Next.js, pero con un código lleno de tareas pendientes que hacen que la próxima actualización sea aún más difícil.
- Costes imprevistos: La estimación inicial era de cuatro semanas. Diez semanas después, los contratistas siguen trabajando, las funciones siguen retrasadas y el coste de oportunidad se mide en el retraso del trabajo en el producto que los clientes estaban esperando.
La actualización es la solución adecuada a largo plazo. Sin embargo, precipitarse a actualizar bajo la presión del cumplimiento normativo es una forma concreta y previsible de fracasar, y la afirmación de que «tenemos que hacerlo ahora» rara vez es cierta cuando existen otras opciones.
La solución fácil: TuxCare ELS para Next.js EOL
Aquí es donde el soporte de ciclo de vida ilimitado de TuxCare para Next.js marca realmente la diferencia.
TuxCare lleva más de una década dedicándose a esto, proporcionando parches de seguridad para sistemas operativos, entornos de ejecución, bibliotecas y marcos de aplicaciones que han llegado al final de su ciclo de vida en todo el ecosistema de código abierto. Han distribuido más de 220 000 parches de seguridad. Cuando afirman que saben cómo mantener seguro el software al final de su ciclo de vida a escala empresarial, no se refieren a una capacidad teórica. Cuentan con una trayectoria que lo avala.
¿Qué diferencia al enfoque de TuxCare?
Cobertura completa del árbol de dependencias: TuxCare no solo aplica parches a Next.js; cubre tus dependencias directas y las dependencias transitivas subyacentes, sin coste adicional. El clúster RSC de diciembre de 2025 (CVE-2025-55182) demostró exactamente cómo la exposición al fin de vida útil (EOL) de Next.js se extiende profundamente a través de paquetes ascendentes como React Server Components. La cobertura de TuxCare se extiende a lo largo de toda esa cadena. No solo estás protegiendo el marco; estás asegurando toda la superficie de dependencias de fin de vida útil (EOL) de Next.js.
Proceso de aplicación de parches optimizado y automatizado: El proceso de TuxCare combina la automatización con la validación por parte de expertos. Supervisan el NVD, los avisos de seguridad de los proveedores y los feeds de seguridad de GitHub, todos los lugares donde se revelan las vulnerabilidades de fin de vida útil (EOL) de Next.js. Cuando se publica un CVE, las herramientas algorítmicas y la automatización asistida por IA se encargan de aplicar las correcciones de seguridad, y los expertos en seguridad validan cada parche antes de su lanzamiento. Cada actualización pasa por pruebas de integridad, funcionalidad y regresión antes de llegar a sus repositorios. Para obtener todos los detalles técnicos, consulte el informe técnico de TuxCare sobre su proceso de parcheo de código abierto.
Integración perfecta: Los parches de TuxCare se integran directamente en tu flujo de trabajo actual de npm o Yarn. No tendrás que reformar tu canalización de CI/CD ni volver a formar a tu equipo. Las actualizaciones firmadas y a prueba de manipulaciones se distribuyen desde repositorios alojados por TuxCare que se integran con tus herramientas actuales. Seguirás utilizando exactamente lo que ya has creado.
Respuesta rápida respaldada por el SLA: Cuando se revelan nuevas vulnerabilidades de fin de vida útil (EOL) de Next.js, incluidas aquellas de alta gravedad y que se explotan activamente, como CVE-2025-29927 y la vulnerabilidad RSC de diciembre de 2025 CVE-2025-55182, TuxCare entrega parches en un plazo garantizado respaldado por acuerdos de nivel de servicio reales. No tienes que esperar a que alguien acabe por adaptar una solución. Obtienes actualizaciones listas para producción con las que puedes planificar, con asistencia de expertos las 24 horas del día, los 7 días de la semana, para la clasificación de vulnerabilidades y la resolución de problemas.
Rentabilidad: Esto es lo que siempre sorprende a los equipos sobre el soporte ampliado: suele ser considerablemente más barato que las alternativas. Si se tiene en cuenta con honestidad el tiempo de ingeniería, los ciclos de pruebas, los honorarios de los contratistas, el posible tiempo de inactividad, el retraso en la implementación de funciones y el coste de oportunidad de una migración apresurada, el soporte ampliado suele costar una fracción de ese total. Además, no se agota a su equipo con una migración de alta presión para la que no contaba con los recursos necesarios.
Cumplimiento y transparencia: Cada versión de TuxCare ofrece una visibilidad completa de qué se ha parcheado, qué CVE se han solucionado, qué componentes se han modificado y cómo verificar todo ello en la lista de materiales de software (SBOM). Eso es exactamente lo que necesitan las auditorías PCI DSS, las revisiones SOC 2 y otros marcos de cumplimiento cuando preguntan por el software en fin de vida útil (EOL) en producción.
Cómo empezar
Si utilizas versiones de Next.js que han llegado al final de su ciclo de vida (EOL) y quieres saber exactamente qué vulnerabilidades se han solucionado, TuxCare mantiene un rastreador de CVE en tiempo real: Consulta las vulnerabilidades y correcciones en tiempo real para Next.js aquí.
Para conocer las versiones compatibles, los precios y los detalles de implementación, visita Soporte de ciclo de vida ilimitado de TuxCare para Next.js.
No dejes que el fin del ciclo de vida de Next.js ponga en riesgo tus aplicaciones
Next.js se ha ganado un lugar como uno de los marcos más importantes del entorno web moderno. No va a desaparecer, y el equipo de Vercel sigue impulsando el marco de forma significativa. Pero solo el historial de seguridad de 2025 incluye una vulnerabilidad de elusión de middleware con CVSS 9.1, una vulnerabilidad de ejecución remota de código con CVSS 10.0 y múltiples revelaciones posteriores, lo que deja claro que ejecutar una versión sin soporte no es un riesgo teórico. Es una exposición real y activa con consecuencias reales.
Esto es lo que realmente debes tener claro: el fin de la vida útil (EOL) de Next.js no significa que te quedes sin opciones. Tanto si utilizas una versión de Next.js que ha llegado al final de su vida útil (13, 14 o anterior) como si no, puedes planificar una actualización bien meditada a una versión actual cuando realmente tenga sentido para tu equipo y tu código. Puedes evaluar marcos alternativos si existe una razón arquitectónica real para cambiar. O puedes utilizar el soporte ampliado para mantener la seguridad y el cumplimiento normativo mientras tomas esas decisiones de forma deliberada según tu propio calendario, en lugar de según el de una auditoría de seguridad.
Los equipos que gestionan adecuadamente el fin de la vida útil de Next.js son aquellos que detectan el riesgo a tiempo, comprenden qué recursos tienen realmente a su disposición y toman decisiones meditadas en lugar de reaccionar a los acontecimientos. El soporte ampliado no es una solución provisional, sino una estrategia empresarial legítima para gestionar el intervalo de tiempo que transcurre entre el momento en que finaliza el soporte del proveedor y aquel en que tu equipo está realmente preparado para la migración.
Si el fin de la vida útil de Next.js te preocupa en este momento, visita la página de TuxCare sobre soporte de ciclo de vida ilimitado para software de código abierto para ver cómo el soporte ampliado puede proteger toda tu pila de código abierto durante todo el tiempo que lo necesites.
