Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- El fin de la vida útil (EOL) de Nuxt 3 tendrá lugar el 31 de julio de 2026, con lo que dejarán de ofrecerse parches de seguridad para el marco, Nitro, h3, la integración con Vue 3 y las dependencias incluidas.
- Para aplicaciones Nuxt 3 en buen estado que se ejecutan en una versión moderna de Node.js, la actualización a Nuxt 4 es realmente sencilla. El equipo de Nuxt lo ha diseñado así, con compatibilidad opcional a partir de la versión 3.12 y herramientas de modificación de código que automatizan la mayor parte del trabajo.
- Hay tres situaciones en las que el soporte prolongado resulta una opción más adecuada que la actualización: una decisión estratégica de saltarse Nuxt 4 y esperar a Nuxt 5, entornos regulados que no permiten ventanas de migración y una gran cantidad de módulos de Nuxt de terceros que aún no se han adaptado a la versión 4.
Si estás utilizando Nuxt 3 en producción, es probable que la fecha de fin de vida útil (EOL), fijada para el 31 de julio de 2026, no te haya causado el mismo pánico que han provocado los plazos de otros marcos de trabajo. Bien. No debería. El equipo de Nuxt ha sido transparente en cuanto a lo que implica la actualización y, para la mayoría de las aplicaciones, se trata de un trabajo de alcance limitado.
Dicho esto, la expresión «la mayoría de las aplicaciones» tiene un gran peso en esa frase. Existen razones de peso por las que un equipo podría decidir que actualizar a Nuxt 4 en este momento no es la mejor opción. Este artículo trata sobre esas razones y sobre cuáles son tus opciones si te encuentras en alguna de ellas.
Cómo funciona realmente el control de versiones de Nuxt
Política de soporte de Nuxt: cada versión principal cuenta con un mínimo de seis meses de soporte técnico tras el lanzamiento de la siguiente versión principal. Las actualizaciones de parches se publican aproximadamente cada semana y las versiones secundarias, cada mes, reservándose los cambios que afectan a la compatibilidad para las versiones principales.
Nuxt 3 salió al mercado en noviembre de 2022, como parte de la modernización general del ecosistema tras el hito del fin de vida útil (EOL) de Vue 2. Nuxt 4 se convirtió en la versión principal actual a mediados de 2025. El fin de vida útil (EOL) original de Nuxt 3 estaba fijado para el 31 de enero de 2026, pero el equipo de Nuxt lo amplió en respuesta a los comentarios de la comunidad, y la fecha límite actual es el 31 de julio de 2026. A partir de esa fecha, la línea 3.x dejará de recibir actualizaciones.
Nuxt 5 se encuentra en fase de desarrollo activo. Nitro v3 y h3 v2 están casi listas. Una vez que se lance Nuxt 5, Nuxt 4 llegará al final de su ciclo de vida seis meses después. Ese calendario es importante para el resto de este debate.
Qué significa realmente el fin de la vida útil (EOL) de Nuxt 3
Una vez que Nuxt 3 llegue al final de su ciclo de vida el 31 de julio de 2026, el equipo de Nuxt dejará de publicar parches de seguridad para la línea 3.x. Las vulnerabilidades (CVE) que se den a conocer después de esa fecha no contarán con una solución oficial.
El historial de vulnerabilidades de Nuxt 3 es real, no teórico. A continuación se presentan tres ejemplos de los últimos 18 meses que ilustran el tipo de problemas que surgen en cualquier marco de trabajo en producción:
CVE-2025-27415 (CVSS 7,5, Alto): Una vulnerabilidad de envenenamiento de caché en la CDN que afecta a las versiones de Nuxt 3.0.0 a 3.16.0. Un atacante envía una solicitud como https://yoursite.com/?/_payload.json. Nuxt devuelve una respuesta con una carga útil en formato JSON. Si la clave de caché de tu CDN ignora las cadenas de consulta, ese JSON se almacena en caché con la URL base y se muestra a los visitantes legítimos, por lo que tu sitio web parece no funcionar. El ataque no requiere autenticación y puede automatizarse para mantener la indisponibilidad de forma persistente. Corregido en Nuxt 3.16.0.
CVE-2024-34343 (CVSS 5.1, moderado): Una vulnerabilidad de tipo «cross-site scripting» en navigateTo. La función intentó bloquear el javascript: protocolo, pero se basaba en una lógica de análisis que devolvía valores vacíos para las URL mal formadas, lo que permitía eludir la comprobación del protocolo. Corregido en Nuxt 3.12.4.
CVE-2024-34344 (CVSS 8,8, Alto): Ejecución remota de código a través del navegador al ejecutar Nuxt en modo de prueba de forma local. El NuxtTestComponentWrapper cargaba rutas de componentes sin una validación suficiente, lo que permitía que una página web maliciosa, abierta en el mismo navegador, ejecutara código JavaScript arbitrario en el servidor de pruebas. Corregido en la versión 3.12.4.
Estos problemas se detectaron y solucionaron durante el periodo de soporte activo. La próxima vulnerabilidad de gravedad similar después del 31 de julio de 2026 no se solucionará.
En entornos regulados, esto se convierte en un problema de cumplimiento normativo antes que en uno de seguridad. La norma PCI DSS exige que las vulnerabilidades de alta gravedad se corrijan en un plazo de 30 días desde su divulgación. Los auditores de SOC 2 señalan el software sin soporte técnico presente en las pilas de producción. Los entornos FedRAMP consideran los componentes al final de su ciclo de vida (EOL) como incidencias.
La superficie oculta: el árbol de dependencias de Nuxt
Una aplicación Nuxt 3 en producción no se ejecuta con un solo paquete. El valor predeterminado nuxt La instalación incluye:
- Vue 3 y el
@vue/*paquetes como capa de representación - Nitro como motor del servidor
- h3 como el marco HTTP subyacente de Nitro
- Vite como herramienta de compilación
- El ecosistema de unjs (
ufo,c12,consola,defu,hookable,jiti, entre otros) para servicios compartidos - En
@nuxt/*paquetes básicos (@nuxt/kit,@nuxt/schema,@nuxt/vite-builder,@nuxt/devtools)
Cada uno de estos paquetes tiene su propia cadena de dependencias subyacente. El árbol completo de paquetes empaquetados de una aplicación Nuxt 3 abarca cientos de paquetes. Cualquier vulnerabilidad CVE que se encuentre en cualquier parte de ese árbol, ya sea directa o transitiva, supone una exposición que no se corregirá en el código fuente tras el fin de vida útil (EOL) de Nuxt 3 el 31 de julio de 2026.
La vulnerabilidad de envenenamiento de caché (CVE) mencionada anteriormente se encontraba en el núcleo de gestión de solicitudes de Nuxt. El navigateTo La vulnerabilidad CVE se encontraba en la interacción entre Nuxt y una utilidad de unjs. La exposición a caracteres de fin de línea (EOL) se extiende por toda esta superficie empaquetada, no solo por el nuxt el propio paquete. Un parche solo para el marco de trabajo no sirve de nada si la próxima vulnerabilidad aparece en Nitro o en alguno de los paquetes de unjs.
Módulos opcionales que se instalan por separado (@nuxt/image, @nuxt/content, @nuxt/ui, módulos comunitarios de @nuxtjs/* y en otros lugares) quedan fuera de este conjunto. Tienen sus propios ciclos de lanzamiento y sus propios historiales CVE, y requieren una estrategia de parches específica.
Tus opciones cuando Nuxt 3 llegue al final de su ciclo de vida
Tres caminos reales, cada uno con argumentos claros que justifican cuándo es el adecuado.
Opción 1: Actualizar a Nuxt 4
Para la mayoría de los equipos, esta es la respuesta correcta. El equipo de Nuxt diseñó Nuxt 4 específicamente para que esta migración resulte sencilla. Puedes activar el comportamiento de Nuxt 4 desde Nuxt 3.12 o versiones posteriores utilizando compatibilityVersion: 4 en tu nuxt.config.ts, prueba de forma aislada y migra a tu propio ritmo. Los codemods oficiales automatizan la reestructuración de los directorios para app/, los cambios de nombre en las API y el paso a la reactividad superficial para useFetch.
Según la propia evaluación publicada por el equipo de Nuxt, la mayoría de los proyectos de Nuxt 3 pueden actualizarse con un mínimo esfuerzo. Esto coincide con los informes de los equipos que ya lo han hecho.
Lo que realmente debes tener en cuenta a la hora de hacer el presupuesto:
- Se requiere como mínimo Node.js 18.20. Si tu cadena de herramientas está fijada en una versión anterior, es necesario realizar una migración previa.
- La reestructuración del directorio a
app/. Codemod se encarga de la parte mecánica. No obstante, es recomendable que compruebes los patrones de observadores, las configuraciones de capas y cualquier ruta personalizada. - Reactividad superficial por defecto.
useFetchyuseAsyncDataEn Nuxt 4, los datos son de reactividad superficial. El código que depende de la reactividad profunda requiere una activación explícita. - Compatibilidad de módulos. De origen propio
@nuxt/*Los módulos están actualizados. Los módulos de la comunidad varían. - Verificación de la infraestructura de pruebas.
En el caso de una aplicación bien mantenida, que utilice una versión actual de Node y tenga un tamaño de módulo reducido, esto lleva días, no semanas. La razón por la que existe esta sección, en lugar de limitarme a remitirte a la guía de actualización, es que la descripción «bien mantenida, versión actual de Node, tamaño de módulo reducido» no se ajusta a todas las aplicaciones de Nuxt 3 que están en producción.
Opción 2: Migrar a un marco alternativo
Si ya estás barajando la posibilidad de cambiar de modelo de renderizado o de entorno de ejecución, el fin de la vida útil (EOL) de Nuxt 3 es un factor decisivo para dar ese paso. Las opciones viables para los equipos que trabajan con Vue son más limitadas que para los que utilizan React. Puedes pasar a Vue 3 sin más, junto con Vite, para aplicaciones de página única (SPA); cambiar a Astro para sitios web con gran cantidad de contenido; o cambiar de ecosistema por completo.
Cada una de ellas conlleva los costes habituales de la migración de un marco de trabajo: reescribir componentes, sustituir el enrutamiento y la obtención de datos, reconstruir la infraestructura de pruebas y renunciar al ecosistema de módulos específico de Nuxt. Para la mayoría de los equipos que utilizan Nuxt 3 en producción, las cuentas no salen a favor de esta opción. Se incluye aquí más por completar la información que como una recomendación probable.
Opción 3: Soporte ampliado con TuxCare ELS
Esta es la opción más adecuada en tres situaciones concretas.
La decisión estratégica de saltarse Nuxt 4. El equipo de Nuxt ha dejado claro que Nuxt 4 es una versión de transición. Nuxt 5 incorpora Nitro 3, la API de entornos de Vite 6 y cambios internos en h3. El número de incompatibilidades entre la versión 4 y la 5 es mayor que entre la 3 y la 4. Además, Nuxt 4 dejará de recibir soporte seis meses después del lanzamiento de Nuxt 5.
Si migras ahora de la versión 3 a la 4, te estarás comprometiendo a realizar otro ciclo de migración una vez que se lance Nuxt 5. El equipo de Nuxt ha indicado que Nuxt 5 se encuentra en fase de desarrollo activo, y que Nuxt 4 llegará al final de su ciclo de vida (EOL) seis meses después del lanzamiento de Nuxt 5. Siendo realistas, eso supone dos migraciones en producción en un plazo relativamente corto.
La alternativa es seguir con Nuxt 3 con la cobertura de ELS, saltarse Nuxt 4 por completo y pasar directamente de la versión 3 a la 5 una vez que Nuxt 5 se haya estabilizado. Una migración en lugar de dos. La cuestión es si ELS resulta más económico que una actualización intermedia innecesaria, lo cual, para la mayoría de los equipos empresariales, es claramente así.
Entornos sujetos a requisitos de cumplimiento normativo. Normativas como PCI DSS, SOC 2, FedRAMP y otros marcos similares exigen pruebas de que el software está actualizado y cuenta con soporte técnico. No admiten un proyecto de migración de seis semanas solo porque haya llegado el auditor. Si tienes un plazo de auditoría dentro del periodo posterior al fin de vida útil (EOL) y tu entorno no puede completar la migración a Nuxt 4 en ese tiempo, ELS proporciona el código fuente de los parches y el historial de documentación necesarios para cumplir con los requisitos de control.
Esto también se aplica a entornos con versiones fijas de Node.js, a aplicaciones implementadas por el cliente o de marca blanca en las que no es posible forzar las actualizaciones de versión, y a cualquier contexto en el que el riesgo asociado al cambio deba amortizarse en lugar de aceptarse de una sola vez.
Retraso en el ecosistema de módulos. Cuando se lanzó Nuxt 4, el núcleo @nuxt/* Los paquetes se han actualizado sin problemas. Los módulos oficiales opcionales y los módulos de la comunidad han tardado más en actualizarse, y algunos aún no se han migrado. Si tu aplicación depende de una larga lista de estos módulos, es posible que te veas bloqueado por mantenedores sobre los que no tienes control hasta que lancen la compatibilidad con Nuxt 4.
ELS para Nuxt 3 garantiza la seguridad del marco y sus dependencias integradas mientras esperas. No aplica parches a los módulos opcionales ni a los de la comunidad, cuya responsabilidad sigue recayendo en sus mantenedores o en tu propio equipo. Lo que hace es eliminar la presión por parte del marco para migrar antes de que las dependencias de tus módulos estén listas.
Ninguno de estos casos se aplica a todas las aplicaciones de Nuxt 3. Los tres son casos reales, y cualquiera de ellos constituye una razón válida para planificar la estrategia en torno al fin de vida útil (EOL) de Nuxt 3 con soporte ampliado, en lugar de precipitarse a realizar una migración que no se adapte a la situación del equipo.
Qué ofrece TuxCare ELS para Nuxt 3
El servicio de soporte de ciclo de vida ilimitado de TuxCare para Nuxt 3 EOL ofrece parches de seguridad continuos tras la fecha límite del 31 de julio de 2026. La cobertura incluye: nuxt paquete, sus dependencias directas y sus cadenas transitivas: Vue 3 y el @vue/* paquetes, Nitro, h3, Vite, el @nuxt/* los paquetes principales, las utilidades del ecosistema unjs y los paquetes más complejos de los que dependen. Los parches se distribuyen a través de los flujos de trabajo estándar de npm.
Módulos opcionales que se instalan por separado (@nuxt/image, @nuxt/content, @nuxt/ui, @nuxtjs/*, módulos comunitarios) no forman parte del ámbito predeterminado.
Algunos detalles que son habituales en TuxCare en toda la gama de productos ELS:
- Flujo de trabajo de aplicación de parches. TuxCare supervisa el NVD, los avisos de seguridad de GitHub y los canales de los proveedores. Cuando se da a conocer un CVE que afecta a los paquetes incluidos en el ámbito de cobertura, las adaptaciones se someten al proceso combinado de automatización y revisión por expertos de TuxCare. Cada parche se somete a pruebas de integridad, funcionalidad y regresión antes de llegar a sus repositorios.
- Método de entrega. Los parches se distribuyen a través de repositorios compatibles con npm alojados en TuxCare. Sin cambios en CI/CD, sin nuevas herramientas y sin necesidad de reescribir el proceso de compilación.
- Documentación de cumplimiento. Cada versión incluye un registro de las vulnerabilidades CVE que se han solucionado y de los paquetes que se han modificado, lo cual cumple con los requisitos de evidencia de PCI, SOC 2 y FedRAMP.
- Respuesta respaldada por el SLA. Las vulnerabilidades CVE críticas y de alto riesgo (CVSS 7.0+) se comprometen a resolverse dentro de un plazo de entrega definido.
Para obtener información técnica detallada sobre el proceso de aplicación de parches de TuxCare, consulte el informe técnico sobre la aplicación de parches en software de código abierto, donde se trata el tema en profundidad: «Proceso de aplicación de parches en software de código abierto de TuxCare».
La conclusión sincera
Para la mayoría de las aplicaciones de Nuxt 3, actualizar a Nuxt 4 es la decisión acertada. La migración cuenta con un buen soporte técnico y el equipo de Nuxt ha hecho todo lo necesario para que resulte sencilla.
Existe soporte ampliado para aquellas aplicaciones en las que no lo hay. Equipos que han tomado la decisión deliberada de saltarse Nuxt 4 y esperar a Nuxt 5. Aplicaciones sujetas a plazos de cumplimiento que no permiten la migración. Códigos base que dependen de módulos de la comunidad que aún no se han actualizado. Si tu situación se encuentra en este grupo, ELS te ofrece un nivel mínimo de seguridad mientras esperas el momento adecuado o la actualización correspondiente del código fuente.
El error radica en considerar la fecha de fin de vida útil (EOL) de Nuxt 3 como una imposición ineludible, cuando en realidad no lo es. El equipo de Nuxt ha diseñado la ruta de actualización para que sea fluida. Además, han dejado claro que Nuxt 4 es una versión de transición y que Nuxt 5 está al caer. Ambos factores deben tenerse en cuenta a la hora de tomar una decisión, no solo uno de ellos.
Para saber si el servicio ELS para Nuxt 3 se adapta a tu entorno, visita la página de TuxCare sobre el servicio Endless Lifecycle Support para Nuxt o ponte en contacto con nosotros para analizar tu pila tecnológica.
