Fin del soporte técnico de Node.js 18 y opciones de migración

Principales conclusiones

• Node.js 18 dejó de recibir soporte el 30 de abril de 2025 y ya no recibe actualizaciones de seguridad ni correcciones de errores por parte del proyecto Node.js.
• El proyecto considera que todas las versiones que han llegado al final de su ciclo de vida se ven afectadas cada vez que se publica una actualización de seguridad, por lo que el número de vulnerabilidades sin parchear en Node.js 18 aumenta según su calendario, no según el tuyo.
• Node.js 24 es actualmente la única versión LTS activa. Node.js 22 ya se encuentra en fase de mantenimiento LTS y llegará al final de su ciclo de vida el 30 de abril de 2027, lo que la convierte en una opción poco recomendable para la migración.
• El servicio de soporte de ciclo de vida ilimitado de TuxCare mantiene Node.js 18 actualizado con los parches correspondientes a las vulnerabilidades conocidas, mientras los equipos planifican y prueban la migración a un ritmo realista.

Casi nadie decide utilizar una versión que ha llegado al final de su ciclo de vida. Los equipos acaban en esa situación porque las solicitudes de actualización siempre quedan relegadas frente al trabajo de lanzamiento de productos y porque, a simple vista, todo parece funcionar correctamente. Node.js 18 llegó al final de su ciclo de vida el 30 de abril de 2025 —hace más de un año— y, desde entonces, no ha recibido parches de seguridad, correcciones de errores ni soporte oficial por parte del proyecto Node.js.

Lo que suele pillar desprevenidos a los equipos es la gestión. La postura del propio proyecto Node.js es que las versiones al final de su ciclo de vida se ven afectadas cada vez que se publica una actualización de seguridad, independientemente de que alguien las vuelva a probar o no. Por lo tanto, tu superficie de vulnerabilidad sin parches aumenta cada vez que el proyecto publica un aviso, a un ritmo que no puedes controlar.

Esta guía aborda el calendario de fin de vida útil (EOL) de Node.js 18, qué versión deberías elegir realmente como objetivo en 2026 —probablemente no sea la más obvia— y cómo mantenerte al día con los parches si la migración no se puede llevar a cabo este trimestre.

Información sobre el fin de la vida útil de Node.js 18

Es útil saber cómo estructura realmente el Grupo de Trabajo de Lanzamientos de Node.js el soporte técnico. Hay tres fases de soporte, y el «fin de vida útil» es el estado al que llega una línea de versiones una vez que estas han finalizado.

Versión actual: Una nueva versión principal permanece en la línea «Actual» durante unos seis meses, lo que da tiempo a los autores de las bibliotecas para añadir compatibilidad con ella. La recomendación del proyecto es que las aplicaciones en producción solo ejecuten versiones Active LTS o Maintenance LTS.

LTS activa: Tras unos seis meses, las versiones pares pasan a la categoría de LTS activa durante unos 12 meses. Esta fase abarca más que las correcciones de emergencia: incluye nuevas funcionalidades, correcciones de errores y actualizaciones que el equipo de lanzamientos ha revisado y considerado adecuadas y estables para esa línea. Las líneas impares nunca pasan a esta categoría, por lo que las versiones 23 y 25 pasaron de «Actual» al fin de su ciclo de vida sin pasar por ninguna fase LTS.

Mantenimiento: Tras la fase de LTS activa, hay un periodo de mantenimiento de aproximadamente 18 meses, que se limita a la corrección de errores críticos y a las actualizaciones de seguridad. Rara vez se incorporan nuevas funciones, y normalmente solo cuando te ayudan a migrar a una versión posterior.

Esto supone unos 36 meses desde el lanzamiento inicial hasta el fin de la vida útil, de los cuales aproximadamente 30 meses están cubiertos por la versión LTS.

Un cambio que conviene tener en cuenta: este modelo de versiones pares e impares solo se aplica hasta Node.js 26. A partir de Node.js 27, Node.js pasa a tener una única versión principal al año, y cada versión principal pasará a ser LTS tras su fase «Current». Si estás eligiendo una versión de referencia hoy, la fase es más importante que el número de versión: una línea que ya se encuentre en «Maintenance» está a punto de quedar obsoleta, por muy reciente que parezca.

Fin de la vida útil de Node.js 18: fechas clave

Node.js 18 (nombre en clave «Hydrogen») se lanzó el 19 de abril de 2022. Entró en la fase de soporte activo a largo plazo (LTS) el 25 de octubre de 2022, pasó a la fase de mantenimiento el 18 de octubre de 2023 y llegó al final de su ciclo de vida el 30 de abril de 2025.

 

Por dónde empezar: Comprueba qué es lo que realmente estás ejecutando antes de planificar nada, ya que en la mayoría de los entornos no se trata de una sola versión. Ejecuta el comando `node -v` en cada host y, a continuación, revisa tus archivos Dockerfile, las imágenes de CI y cualquier configuración de tiempo de ejecución gestionada en Lambda, App Runner o la plataforma que utilices.

Riesgos de Node.js 18 tras el fin de su ciclo de vida

Seguir utilizando Node.js 18 una vez finalizado su ciclo de vida no supone ninguna interrupción desde el primer día, y esa es precisamente la razón por la que los sistemas siguen funcionando así. Todo sigue funcionando. Las API siguen respondiendo. No se envía ningún aviso a nadie.

Lo que ha cambiado es que han dejado de publicarse correcciones, mientras que se siguen detectando vulnerabilidades. Los riesgos que se enumeran a continuación se acumulan, y cada uno de ellos resulta más económico de gestionar en una ventana de actualización planificada que durante un incidente. Mientras Node.js 18 estaba en soporte, recibía parches de seguridad al igual que el resto de versiones en mantenimiento. Esas publicaciones cesaron en abril de 2025, y el proyecto Node.js no publicará más correcciones para esta versión.

Aumento de la exposición a las vulnerabilidades CVE

La postura oficial del proyecto es un argumento útil si necesitas justificar el trabajo a nivel interno: las versiones al final de su ciclo de vida siempre se ven afectadas cuando se publica una actualización de seguridad. Node.js no vuelve a probar las versiones al final de su ciclo de vida, por lo que sus avisos solo incluyen las versiones compatibles; sin embargo, las rutas de código vulnerables siguen estando presentes en la versión 18 y no se prevé ningún parche oficial para ellas.

La actualización de seguridad del 13 de enero de 2026 es un buen ejemplo. Solucionó ocho vulnerabilidades en todas las líneas compatibles, incluidas estas cuatro:

• CVE-2025-55131 (Alta) – Una condición de carrera basada en el tiempo de espera hace que Buffer.alloc y las matrices tipadas no se rellenen con ceros, lo que deja al descubierto memoria no inicializada. Se puede acceder a ella a través del módulo vm con tiempos de espera de ejecución, lo que resulta especialmente relevante cuando se ejecuta código de confianza parcial.
• CVE-2025-59465 (Alta) – Una trama HEADERS de HTTP/2 mal formada que contiene datos HPACK no válidos provoca el bloqueo del proceso debido a un error no gestionado en el socket TLS.
• CVE-2025-59466 (Medio): un error de «Se ha superado el tamaño máximo de la pila de llamadas» no se puede interceptar cuando async_hooks está activo, lo que elude process.on(‘uncaughtException’). El alcance de este problema es mayor de lo que parece a primera vista: AsyncLocalStorage se basa en async_hooks, por lo que Next.js, los componentes de servidor de React y la mayoría de los agentes APM se ven afectados.
• CVE-2026-21637 (Medio) – Las excepciones lanzadas desde las funciones de devolución de llamada de TLS PSK o ALPN eluden los controladores de errores, lo que provoca una denegación de servicio y una fuga de descriptores de archivo.

Esas correcciones se incluyeron en las versiones 20.20.0, 22.22.0, 24.13.0 y 25.3.0. No existe un equivalente para la versión 18.x, ni lo habrá.

Nota sobre las herramientas: El proyecto Node.js mantiene el paquete «is-my-node-vulnerable», que compara la versión que tienes instalada con la base de datos de seguridad de Node.js. Ejecuta «npx is-my-node-vulnerable». Sin embargo, ten en cuenta cómo se comporta en un entorno de ejecución EOL: en lugar de enumerar los CVE individuales, informa de que la versión ha llegado al final de su vida útil y la considera vulnerable por defecto, ya que las versiones EOL no se comparan con las últimas actualizaciones de seguridad. Para obtener detalles por CVE y el estado de los parches en las versiones compatibles con TuxCare, utiliza el CVE Tracker.

 

Incumplimientos

Un entorno de ejecución EOL rara vez falla por sí solo en una auditoría. Lo que hace es eliminar la forma más sencilla de cumplir los controles de gestión de vulnerabilidades establecidos en PCI DSS, HIPAA, RGPDe ISO 27001, que, por lo general, exigen que se identifiquen las vulnerabilidades conocidas y se subsanen en un plazo determinado.

La norma PCI DSS es la que establece los requisitos más específicos en cuanto a los plazos. El requisito 6.3.3 exige que los parches de seguridad críticos se instalen en el plazo de un mes desde su publicación. Cuando el proyecto original ha dejado de publicar parches para tu entorno de ejecución, no puedes cumplir ese requisito mediante la aplicación de parches, por lo que te ves obligado a demostrar que dispones de controles compensatorios.

También hay un problema con el escáner que sorprende a la gente. El propio proyecto Node.js emite ahora CVE para las versiones que han llegado al final de su ciclo de vida, que se registran como «sin soporte» cuando se asignan bajo el código CWE-1104, «uso de componentes de terceros sin mantenimiento». Por lo tanto, Node.js 18 puede aparecer como un hallazgo en herramientas como npm audit o Snyk simplemente por haber llegado al final de su ciclo de vida, independientemente de cualquier error concreto.

Si te encuentras dentro del ámbito de la auditoría: elija ahora su estrategia: actualización, aplicación de parches comerciales o controles compensatorios documentados. Las tres opciones son defendibles. Descubrir durante la auditoría sobre el terreno que no cuenta con ninguna de ellas, en cambio, no lo es.

Dependencias y rotura del ecosistema

Las aplicaciones modernas de Node.js se basan en un amplio árbol de dependencias, y ese árbol cambia sin avisar. Los paquetes, los marcos de trabajo y los servicios en la nube dejan de dar soporte a las versiones antiguas de los entornos de ejecución según sus propios calendarios. AWS, por ejemplo, dejó de ofrecer soporte para Node.js 18.x en el AWS Cloud Development Kit el 30 de noviembre de 2025, lo que afecta a la CLI del CDK, la biblioteca «construct» y proyectos relacionados como JSII, Projen y CDK8s.

El patrón es previsible. Las nuevas versiones de los paquetes dejan de ser compatibles con las versiones anteriores de Node.js, por lo que los equipos fijan las versiones para que todo siga funcionando, y el árbol de versiones fijadas también queda fuera de soporte. Cuanto más tiempo se permanece en esa situación, más deuda técnica se acumula, hasta que las actualizaciones rutinarias empiezan a requerir primero una actualización del entorno de ejecución.

Ejemplo: Un equipo que utiliza una API de Node.js 18 necesita aplicar un parche para corregir una vulnerabilidad en una biblioteca de registro. La versión corregida requiere Node.js 20 o posterior. La actualización del entorno de ejecución no está programada, por lo que siguen utilizando la versión vulnerable. El parche existe, pero aún así no pueden aplicarlo.

Esa es la verdadera naturaleza del riesgo de fin de vida útil (EOL). Por lo general, se manifiesta a través del árbol de dependencias, más que en el propio tiempo de ejecución.

Riesgo operativo y depuración más compleja

Una vez finalizado el ciclo de vida, el proyecto Node.js deja de ofrecer correcciones de errores y asistencia técnica para esa versión, y la atención de la comunidad se centra en las versiones que siguen recibiendo soporte.

Esto cambia la respuesta ante incidentes de una forma concreta: tienes que depurar sin ayuda de los desarrolladores originales. Si te encuentras con un error real del entorno de ejecución, no hay que esperar a que se porte una corrección, no hay evaluación por parte del responsable del mantenimiento y cada vez hay menos debate en la comunidad sobre una versión que ya casi nadie utiliza. Los perfiladores, los depuradores y los agentes APM también dejan de ser compatibles con entornos de ejecución antiguos, por lo que es posible que las herramientas a las que recurrirías normalmente no se puedan conectar.

Prepárate para ello: si por ahora vas a seguir con la versión 18, ten en cuenta que el tiempo medio de resolución de cualquier incidencia relacionada con el tiempo de ejecución será mayor, y ten a mano un entorno de depuración reproducible de la versión 18.x para no tener que crearlo en pleno incidente.

Tus opciones ahora que Node.js 18 ha llegado al final de su ciclo de vida

Ahora que el proyecto Node.js ya no ofrece soporte para Node.js 18, cada equipo debe tomar una decisión. Quedarse como está es una de las opciones disponibles; simplemente, no suele quedar constancia de ello por escrito, y así es como acaba convirtiéndose en la opción por defecto.

	No hacer nada	Actualizar a una versión LTS compatible	Asistencia ampliada
Esfuerzo inicial	Bajo	Alta	Bajo
Esfuerzo recurrente	Seguimiento, aprobación de riesgos, pruebas de auditoría	Ninguna tras la transición	Bajo
Parches de seguridad	Ninguno	Oficial y en curso	En curso, para las vulnerabilidades afectadas
Riesgo de seguridad	Crece con cada lanzamiento	Mínimo	Rebajado
Deuda técnica	Crece	Autorizado	Sigue creciendo
Ideal para cuando	Aislado y a punto de ser desmantelado	Este trimestre hay capacidad disponible	La actualización tardará dos o más trimestres en llegar

No hacer nada

No hacer nada es la opción más barata este trimestre y la más cara a largo plazo. Cuando un sistema es estable y no hay ningún problema, la tentación de dejarlo tal cual es muy fuerte.

No tiene por qué ser necesariamente una decisión errónea. Un servicio que esté realmente aislado, que no gestione datos regulados y cuya fecha de desmantelamiento, ya financiada, se sitúe dentro de uno o dos trimestres, puede que ni siquiera merezca la pena migrarlo.

Lo que hace que sea una decisión errónea es darlo por sentado. No hacer nada sigue suponiendo un coste en términos de supervisión de vulnerabilidades, aprobación de la aceptación de riesgos, documentación de auditoría y una posición más débil cuando algo sale mal. Esas horas son reales y se repiten.

Punto de decisión: Si el servicio está expuesto a Internet o entra dentro del alcance de la auditoría, esta opción queda descartada. Si está aislado y está previsto su desmantelamiento, documenta formalmente la aceptación del riesgo y pasa a tareas más útiles.

Actualización a una versión LTS compatible

La actualización es la única opción que resuelve el problema de forma definitiva, en lugar de limitarse a gestionarlo. A partir de agosto de 2026, estas son las opciones entre las que puedes elegir:

• Node.js 24 (Krypton): LTS activa, fin de vida útil el 30 de abril de 2028. La opción predeterminada para la mayoría de los equipos.
• Node.js 22 (Jod): en fase de mantenimiento LTS desde el 21 de octubre de 2025; fin de vida útil el 30 de abril de 2027. Solo se incluyen correcciones de errores críticos y actualizaciones de seguridad.
• Node.js 26 – actualmente en la línea «Current», con promoción a «Active LTS» prevista para octubre de 2026 y fin de vida útil previsto para el 30 de abril de 2029.

 

Fíjate en la trampa que hay en esa lista. Node.js 22 parece la opción más prudente, pero ya ha superado la fase «Active LTS» y le queda menos de un año de soporte, por lo que migrar de la versión 18 a la 22 significa tener que repetir el mismo proceso antes de abril de 2027. A menos que haya algo en tu árbol de dependencias que impida específicamente pasar a la versión 24, no merece la pena el esfuerzo de pasar a la 22.

La actualización restablece el soporte oficial de seguridad y te devuelve a un entorno de ejecución con el que sigue siendo compatible el ecosistema en general. Lo que no va a pasar es que se haga en una tarde. Pasar de la versión 18 a la 24 implica cruzar dos líneas LTS y varias versiones principales de V8: hay que recompilar los módulos nativos según la nueva ABI, hay que comprobar las compilaciones de node-gyp y los binarios precompilados, y las compilaciones oficiales para Linux requieren una glibc más reciente que las de Node.js 18, lo cual es suficiente para descartar las distribuciones más antiguas sin un cambio en la imagen base. Prevé un presupuesto para un ciclo de pruebas completo en el entorno de staging, en lugar de limitarte a un simple cambio de versión en la integración continua (CI).

Consejo profesional: Sáltate Node.js 20. Llegó al final de su ciclo de vida el 30 de abril de 2026, por lo que migrar a esa versión supone dar un paso lateral hacia otro entorno de ejecución sin soporte. Si tu migración se lleva a cabo después de que Node.js 26 entre en LTS en octubre de 2026, la versión 26 contará con el periodo de soporte previsto más largo; sopésalo frente al historial de producción más extenso de la versión 24 y su mayor compatibilidad con dependencias. En cualquier caso, recuerda que el proyecto señala que las fechas previstas están sujetas a cambios.

Asistencia durante todo el ciclo de vida de TuxCare

No todos los sistemas pueden actualizarse dentro del calendario del proyecto. Los largos ciclos de validación, los procesos de aprobación de cambios, las pilas de software certificadas y las aplicaciones suministradas por los proveedores retrasan la fecha realista en trimestres, en lugar de en semanas.

Con el soporte de ciclo de vida ilimitado de TuxCare, Node.js 18 sigue recibiendo parches de seguridad para las vulnerabilidades cubiertas tras el fin oficial de su ciclo de vida. Los parches se proporcionan sin necesidad de modificar el código de la aplicación, lo que hace que este enfoque sea viable para los equipos que no pueden recertificar una aplicación en este momento. TuxCare cubre las versiones 12, 14, 16, 18 y 20 de Node.js.

Considéralo más bien un paso intermedio que un objetivo final. Aborda la parte del problema relacionada con los parches y la gestión de vulnerabilidades. No evita que tu árbol de dependencias se desvíe ni que tu deuda técnica siga aumentando, y la actualización tendrá que realizarse tarde o temprano.

Punto de decisión: Si es realista pensar que se pueda lanzar la actualización este trimestre, actualiza y omite la solución provisional. Si la fecha está a dos o más trimestres vista, o si estás sujeto a una auditoría y no puedes aplicar parches, utiliza una solución provisional y mantén la financiación para la migración.

Protege tus cargas de trabajo de Node.js 18 con TuxCare

Node.js 18 no ha cambiado. Lo que sí ha cambiado es su estado de soporte. El mismo binario que en abril de 2025 era un entorno de ejecución en mantenimiento es ahora el componente más antiguo sin mantenimiento que subyace a tu aplicación, y acumula nuevas vulnerabilidades sin parchear cada vez que el proyecto lanza una versión de seguridad.

Lo complicado es que la solución más obvia conlleva una respuesta errónea. Node.js 22 es la evolución más intuitiva desde la versión 18 y la que menos tiempo te ahorra. Node.js 24 es el objetivo adecuado para la mayoría de los equipos, pero también supone la migración más exigente. Esa diferencia entre la respuesta fácil y la correcta es precisamente donde el soporte ampliado cobra todo su sentido.

Para aquellas organizaciones que no puedan llegar a ese punto de inmediato, el soporte de ciclo de vida ilimitado para Node.js mantiene las cargas de trabajo de Node.js 18 protegidas contra vulnerabilidades conocidas mientras se planifica y prueba adecuadamente la migración, sin necesidad de realizar cambios en el código de la aplicación.

Si todavía utilizas Node.js 18, decide qué camino seguir este trimestre: actualizar, aplicar una solución provisional o aceptar el riesgo de forma documentada. La única opción que se vuelve más costosa cuanto más tiempo la dejes sin resolver es no elegir nada.

Preguntas frecuentes sobre el fin de la vida útil de Node.js 18