Fin de la vida útil de Node.js: fechas, riesgos y qué hacer a continuación

Ya están disponibles los parches de php2shell (CVE-2026-109618 y CVE-2026-109619) para PHP en fin de vida útil. Dado que las respuestas del departamento de ventas están tardando más de lo habitual debido a la elevada demanda, la forma más rápida de obtener los paquetes parcheados es comprar ELS para Runtimes en línea (se abre en una pestaña nueva). Lee las preguntas frecuentes sobre los parches

Ir directamente al resumen generado por IA de esta entrada del blog

  • Resume esta entrada con Perplexity
  • Resume esta publicación con Gemini

Principales conclusiones

  • Node.js sigue un ciclo de vida LTS predecible de unos 30 meses.
  • Las versiones de Node.js que han llegado al final de su ciclo de vida exponen a los sistemas a vulnerabilidades CVE sin parchear, incumplimientos de normas y problemas de compatibilidad con las dependencias.
  • Lo más seguro es actualizar a una versión LTS compatible siempre que sea posible.
  • Si no es posible realizar una actualización inmediata, TuxCare te ayuda a mantener tus aplicaciones actualizadas y conformes con los requisitos normativos incluso después de que hayan dejado de recibir soporte técnico.

Cuando una versión de Node.js llega al final de su ciclo de vida, el ciclo de soporte ha concluido y los responsables del mantenimiento dejan de publicar parches de seguridad. Cualquier vulnerabilidad que se detecte a partir de esa fecha no será corregida ni por la comunidad ni a través de los canales oficiales. Si tus sistemas siguen ejecutando esa versión, la gestión del riesgo recae exclusivamente en ti.

Esta es ya la realidad para los equipos que utilizan las versiones 12, 14, 16 o 18 de Node.js, todas ellas con el ciclo de vida ya finalizado. La fecha de fin de vida útil de Node.js 20 es el 30 de abril de 2026. Si aún no lo has planificado, se te acaba el tiempo.

En este artículo se explica qué significa el fin de la vida útil (EOL) de Node, las fechas exactas que debes conocer, los riesgos de utilizar una versión sin soporte técnico y las opciones disponibles para tu equipo, incluyendo cómo mantener la seguridad si, por el momento, no está prevista una actualización.

¿Qué significa «Node EOL»?

El fin de vida útil de Node (Node EOL, por sus siglas en inglés) es la fecha en la que el equipo responsable del proyecto Node.js deja de dar soporte a una versión. No se publican correcciones de seguridad para las vulnerabilidades (CVE) recién descubiertas. Se suspenden las correcciones de errores y las actualizaciones del producto. La versión se marca como sin soporte y de riesgo para entornos de producción.

Esto no significa que tu aplicación deje de funcionar. Tu código seguirá ejecutándose. La cuestión es si tus aplicaciones seguirán siendo seguras y cumplirán con la normativa. Si se detecta una vulnerabilidad de seguridad —incluso una de gravedad crítica— en cualquier versión después de su fecha de fin de vida útil, no se solucionará. Tu sistema seguirá expuesto hasta que realices una actualización u optes por el soporte ampliado.

Explicación del ciclo de vida de Node.js

Node.js sigue un calendario de lanzamientos fijo. Cada versión principal pasa por fases de soporte bien definidas antes de llegar al final de su ciclo de vida.

Así es como funciona el ciclo de vida:

Fases del ciclo de vida de Node.js LTS

1. Versión actual

Una nueva versión principal pasa a ser «actual» tras su lanzamiento. Se encuentra en fase de desarrollo activo y se le añaden nuevas funciones. Esta fase dura unos seis meses y no se recomienda su uso en entornos de producción.

2. LTS (soporte a largo plazo) activo

Transcurridos seis meses, las versiones pares (12, 14, 16, 18, 20, 22) pasan a la fase LTS activa. Las versiones impares (13, 15, 17, 19) no obtienen el estatus LTS. Se retiran tras seis meses. Para los sistemas de producción, solo son relevantes las versiones LTS.

Las versiones LTS siguen recibiendo parches de seguridad, correcciones de errores y mejoras de estabilidad durante unos 12 meses.

3. Mantenimiento LTS

Una vez finalizado el periodo de soporte activo (LTS), la versión de Node.js pasa a la fase de mantenimiento (LTS). En esta fase:

  • Se siguen publicando parches de seguridad.
  • Solo se publican correcciones de errores críticos.
  • No se han añadido nuevas funciones.

Esta fase dura unos 18 meses.

4. Fin de vida útil (EOL)

Cuando finaliza el soporte técnico a largo plazo (LTS), la versión llega al final de su ciclo de vida. En ese momento:

  • Ya no se publican más parches de seguridad.
  • No se incluyen correcciones de errores.
  • Esta versión ya no cuenta con soporte técnico oficial.

Nota: En el caso de las versiones de Node.js, desde el inicio del ciclo de vida activo (LTS) hasta la fecha de fin de vida útil (EOL), los usuarios suelen recibir unos 30 meses de soporte técnico. Pasado ese plazo, las organizaciones deben actualizar el software o buscar otra forma de mantener la seguridad.

Fechas de fin de vida útil de los nodos y calendario de soporte

La siguiente tabla recoge todas las versiones LTS de Node.js y sus fechas oficiales de fin de vida útil.

Fechas de fin de vida útil de las versiones LTS de Node.js

Puedes utilizar las fechas de fin de vida útil indicadas anteriormente para comprobar en qué punto se encuentra cada versión y si tu implementación actual entra o queda fuera de las políticas oficiales de soporte. Para comprobar el estado actual de la versión de Node.js que se ejecuta en tu sistema, ejecuta:

node -v

Fin de vida útil de Node 20: lo que debes saber

Node.js 20 llegará al final de su ciclo de vida el 30 de abril de 2026. Para ser una versión que entró en LTS activo en octubre de 2023, ha tenido una amplia adopción en entornos de producción. Sin embargo, a partir del 1 de mayo de 2026, cualquier vulnerabilidad descubierta en Node.js 20 no recibirá un parche oficial. Dada su amplia implantación, es probable que siga siendo un objetivo activo para los investigadores y los actores maliciosos cuando surjan nuevas CVE que afecten a esta versión.

Para los equipos que actualmente utilizan Node 20, la cuestión no es si deben actuar, sino qué medida es la más adecuada teniendo en cuenta sus plazos, su código fuente y sus limitaciones operativas. Actualizar a Node.js 22 es la opción más sencilla si sus dependencias lo admiten.

Si no es así, o si el plazo de migración se prolonga más allá de la fecha de fin de vida útil, el servicio «Endless Lifecycle Support» (ELS) de TuxCare para Node.js proporciona parches de seguridad de forma continua mientras planificas y llevas a cabo la actualización. ELS es compatible con Node.js 12, 14, 16, 18 y 20.

Riesgos de utilizar una versión obsoleta de Node.js

El uso de una versión de Node.js que ha llegado al final de su ciclo de vida (EOL) no provoca un fallo inmediato. Cuando las políticas de soporte establecen que deja de haber parches disponibles, el riesgo se acumula con el tiempo en varios aspectos que son importantes para la seguridad, el cumplimiento normativo y la estabilidad operativa.

Vulnerabilidades de seguridad sin parchear

Cuando se da a conocer una vulnerabilidad CVE que afecta a una versión fuera de soporte, no se publicará ningún parche oficial para ella. Si la misma vulnerabilidad afecta a una línea de versiones con soporte, esa línea se corrige y la solución también se hace pública, lo que, en la práctica, proporciona a cualquiera un mapa detallado de una vulnerabilidad sin resolver en la versión fuera de soporte. Cuanto más tiempo se utilice una versión sin soporte, más se acumularán estas revelaciones.

Para obtener más información sobre cómo las vulnerabilidades sin parchear afectan a los entornos de ejecución heredados, consulta nuestro recurso sobre el fin de vida útil (EOL) de Node.js 18.

Incumplimientos

La mayoría de los marcos de seguridad y normas reguladoras, entre ellos PCI DSS, HIPAA e ISO 27001, exigen que las dependencias de software estén actualizadas y reciban parches de seguridad. El uso de un entorno de ejecución que ha llegado al final de su vida útil (EOL) es un hallazgo habitual en cualquier auditoría. Para los equipos de sectores regulados, esto no es una preocupación teórica, sino un obstáculo real para la certificación y un riesgo en las evaluaciones de seguridad de los proveedores.

Según el Informe sobre el estado del software de código abierto de 2025, las empresas que utilizan software al final de su ciclo de vida, como CentOS, tienen casi tres veces más probabilidades de no superar las auditorías de cumplimiento, un patrón de riesgo que también se aplica a entornos de ejecución sin soporte técnico, como Node.js.

Problemas con las dependencias y la cadena de herramientas

El entorno de ejecución de Node.js no funciona de forma aislada. A medida que el ecosistema avanza, los paquetes de npm dejan de ser compatibles con versiones antiguas, las herramientas de CI/CD actualizan sus propios requisitos y las bibliotecas compartidas del sistema evolucionan. Lo que hoy funciona en una versión que ha llegado al final de su vida útil (EOL) puede que no funcione dentro de seis meses, no porque hayas cambiado nada, sino porque todo lo que lo rodea sí lo ha hecho.

Deriva del ecosistema

Con el paso del tiempo, seguir utilizando una versión al final de su ciclo de vida (EOL) supone quedarse cada vez más rezagado en cuanto a mejoras de rendimiento, características del lenguaje y medidas de seguridad que las versiones más recientes dan por sentadas. Cuanto más tiempo se mantiene el código, más difícil resulta mantenerlo, encontrar personal cualificado y migrar a otra plataforma. El coste de la actualización no disminuye con el tiempo, sino que aumenta.

Opciones tras el fin de la vida útil del nodo

El hecho de que se alcance la fecha de fin de vida útil no deja a tu equipo sin opciones. A continuación te presentamos las opciones viables, sin clasificarlas por orden de preferencia: el contexto determina cuál es la más adecuada.

Actualización a una versión LTS compatible

La ruta de actualización estándar consiste en pasar a Node.js 22, que actualmente se encuentra en fase de mantenimiento LTS, o a Node.js 24, que está en fase activa LTS. En el caso de aplicaciones nuevas o códigos base con dependencias bien mantenidas, esto suele ser sencillo. En el caso de bases de código más grandes o antiguas, las dificultades provienen de dependencias que no se han actualizado, paquetes que no son compatibles con las versiones más recientes de Node o módulos internos que dependen de API que han cambiado. Una auditoría de seguridad antes de comprometerse con un calendario de actualización te indicará rápidamente cuánto trabajo conlleva. En algunos casos, puede requerir meses de validación, lo que aumenta el esfuerzo y el tiempo necesarios para la actualización.

Asistencia durante todo el ciclo de vida de TuxCare

Para los equipos que necesitan más tiempo para llevar a cabo su estrategia de actualización a una versión LTS compatible, el servicio Endless Lifecycle Support (ELS) de TuxCare proporciona parches de seguridad de forma continuada para versiones que han superado su fecha oficial de fin de vida útil. Actualmente, TuxCare ofrece soporte para las versiones 12, 14, 16, 18 y 20 de Node.js, proporcionando parches de seguridad durante todo el tiempo que su equipo los necesite. Esto mantiene sus sistemas y aplicaciones protegidos y en cumplimiento normativo mientras lleva a cabo una migración en un plazo que se adapte a su organización.

El soporte ampliado es un puente, no un destino. El objetivo es llegar a una versión LTS con soporte cuando sea posible. Sin embargo, para los equipos que gestionan cadenas de dependencias complejas, entornos regulados o cuentan con una capacidad de ingeniería limitada, es una forma práctica de evitar cambiar un riesgo (la exposición al fin de vida útil) por otro (una actualización apresurada y sin pruebas suficientes). Para algunas organizaciones, una migración apresurada es más arriesgada que permanecer en una versión antigua.

Con ELS para Node.js, podrás:

  • Reducir la exposición a nuevas vulnerabilidades (CVE)
  • Mantener el nivel de cumplimiento normativo
  • Ganar tiempo para realizar mejoras planificadas
  • Evita las migraciones precipitadas

Visita el gestor de vulnerabilidades CVE para ver las vulnerabilidades que afectan a Node.js y las correcciones disponibles en el ELS de TuxCare para las distintas versiones.

tuxcare cve tracker nodejs els

Cambio de plataforma

Algunos equipos aprovechan el fin de vida útil (EOL) como motivo para evaluar si Node.js sigue siendo el entorno de ejecución adecuado para su carga de trabajo. Cambiar a otro entorno de ejecución o lenguaje rara vez es la opción más rápida, pero a veces merece la pena planteárselo si la aplicación ya necesita una reestructuración moderna. Se trata de una estrategia a largo plazo centrada en garantizar la viabilidad futura, y no de una respuesta a una fecha de fin de vida útil inminente.

Aislar el entorno EOL

En algunos casos, el aislamiento de la red puede ayudar a reducir la superficie de ataque de un sistema que ejecuta una versión fuera de ciclo de vida (EOL). Esto implica limitar el acceso entrante y saliente, reforzar las reglas del cortafuegos y garantizar que el entorno EOL no quede expuesto innecesariamente a redes públicas o a sistemas internos sensibles. El aislamiento no elimina el riesgo, sino que lo contiene. Se trata de una medida de mitigación, no de una solución, y tampoco cumple con los requisitos de cumplimiento normativo.

Asume el riesgo

Esto también es una elección, y vale la pena tenerlo en cuenta. Algunos equipos toman la decisión deliberada de utilizar software al final de su ciclo de vida (EOL) y aceptan el riesgo. El problema es que esta decisión suele tomarse de forma implícita —por omisión— en lugar de mediante una evaluación formal de riesgos. Si tu organización utiliza una versión de Node al final de su ciclo de vida sin una aceptación de riesgos documentada, una estrategia de mitigación activa o un plan de migración, no estás gestionando el riesgo. Lo está ignorando. Esa distinción es importante cuando las cosas salen mal.

Gestiona el fin de vida útil de Node de forma segura con TuxCare

Utilizar una versión de Node.js que ha llegado al final de su vida útil (EOL) es un problema que se puede gestionar, pero solo si se le presta una atención activa. Ignorar la fecha de fin de vida útil o considerarla un riesgo menor es lo que lleva a muchas organizaciones a tener vulnerabilidades CVE sin parchear en su entorno de producción, lo que a su vez genera riesgos de seguridad y hallazgos en las auditorías que no pueden explicar fácilmente.

El enfoque adecuado depende de la situación actual de tu equipo. Si dispones de la capacidad y el soporte necesario para actualizar ahora mismo, deberías optar por Node.js 22 o 24. Si aún no estás en condiciones de hacerlo —ya sea por la complejidad del código, por limitaciones de recursos o porque el plazo de migración se extiende más allá del fin de vida útil (EOL)—, necesitarás una solución de seguridad que cubra ese intervalo.

El servicio de soporte de ciclo de vida ilimitado de TuxCare para Node.js ofrece esa cobertura. Proporciona parches de seguridad para Node.js 12, 14, 16, 18 y 20 durante todo el tiempo que su equipo los necesite, lo que le garantiza una postura de seguridad sólida mientras realiza la migración según el calendario que mejor se adapte a su organización.

Resumen
Fin de la vida útil de Node.js: fechas, riesgos y qué hacer a continuación
Nombre del artículo
Fin de la vida útil de Node.js: fechas, riesgos y qué hacer a continuación
Descripción
¿Te preocupa el fin de la vida útil (EOL) de Node? Descubre cuándo llegan al fin de la vida útil las diferentes versiones, qué riesgos conlleva y cómo planificar tu estrategia de actualización o de soporte ampliado.
Autor
Nombre del editor
TuxCare
Logotipo de la editorial

Únase a más de 4.500 profesionales de Linux y el código abierto.

2 veces al mes. Sin spam.

Índice
Obtenga las respuestas de seguridad de código abierto que necesita

Únase a más de 4.500 profesionales de Linux y el código abierto.

2 veces al mes. Sin spam.