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
- Node.js 20 llegó al final de su ciclo de vida el 30 de abril de 2026, sumándose así a Node.js 18 y a todas las versiones anteriores, que ya no recibirán parches de seguridad por parte del proyecto.
- Una versión de Node.js al final de su ciclo de vida (EOL) implica que las vulnerabilidades CVE que ya se han hecho públicas no se corrigen, y que tampoco se ofrecerán soluciones para las que se descubran posteriormente.
- Cada binario oficial de Node.js incluye aproximadamente 25 componentes. Algunos, como OpenSSL, zlib e ICU, también existen como bibliotecas del sistema que tu sistema operativo actualiza en otros lugares, pero nunca dentro de Node.js; otros, como V8 y undici, no tienen ningún paquete del sistema, por lo que las correcciones del desarrollador original solo te llegan a través de una nueva compilación de Node.js. Todas las copias incluidas dejan de actualizarse al llegar al fin de vida útil (EOL).
- Las opciones de las que dispones son actualizar a una versión LTS compatible, migrar fuera de Node.js o utilizar el soporte ampliado para seguir recibiendo parches mientras planificas la migración según tu propio calendario.
Si parte de tu pila sigue ejecutando Node.js 18 o 20, no eres el único. Las versiones LTS pares se utilizan ampliamente en producción y no dejan de funcionar el día en que finaliza el soporte. Simplemente dejan de recibir correcciones. Node.js 20 superó ese umbral el 30 de abril de 2026, y todas las versiones anteriores ya lo habían superado.
En esta entrada se explica qué versiones de Node.js han superado su fin de vida útil, qué implica esto para la seguridad y el cumplimiento normativo de las aplicaciones desarrolladas con ellas, y las tres opciones viables de cara al futuro: actualizar, migrar o utilizar el soporte ampliado de Node.js para seguir recibiendo parches mientras se toma una decisión.
¿Qué versiones de Node.js han llegado al final de su ciclo de vida?
A partir de julio de 2026, solo tres ramas de lanzamiento seguirán recibiendo actualizaciones del proyecto Node.js: 26.x (actual), 24.x (LTS activa) y 22.x (LTS de mantenimiento). Node.js 20 y todas las versiones anteriores han llegado al final de su ciclo de vida, al igual que las ramas con números impares que nunca entraron en LTS.
| Versión (nombre en clave) | Estado | Finaliza la asistencia técnica |
| 26.x | Actual; entrará en LTS en octubre de 2026 | Abril 30, 2029 |
| 24.x (Krypton) | LTS activa | Abril 30, 2028 |
| 22.x (Jod) | Mantenimiento LTS | Abril 30, 2027 |
| 25.x, 23.x, 21.x, 19.x | Fin de la vida útil; nunca se incorporó a la versión LTS | Junio de 2026 y antes |
| 20.x (Hierro) | Fin de la vida | Abril 30, 2026 |
| 18.x (Hydrogen) | Fin de la vida | Abril 30, 2025 |
| 17.x y versiones anteriores | Fin de la vida | 2023 o antes |
Históricamente, Node.js ha lanzado dos versiones principales al año, y las versiones pares pasan a tener soporte a largo plazo (LTS): aproximadamente seis meses como «Current», doce meses como «Active LTS» con correcciones de errores y de seguridad, y luego una fase de mantenimiento en la que solo se aplican correcciones críticas; esto supone unos 30 meses de LTS, o aproximadamente 36 meses desde el primer lanzamiento hasta el fin de su vida útil.
Ese modelo está cambiando. A partir de Node.js 27, el proyecto pasa a una versión principal al año, cada versión pasa a ser LTS y los números de versión se alinean con el año natural: 27.0.0 en 2027, 28.0.0 en 2028. En octubre de 2026 se abrirá un nuevo canal Alpha para asumir la función de pruebas tempranas que solían desempeñar las líneas impares, y Node.js 26 será la última línea bajo el modelo anterior. El soporte total se mantiene tal y como está, en unos 36 meses desde la primera versión «Current» hasta el fin de su vida útil. Un calendario más predecible, pero el punto final es el mismo: cada línea sigue teniendo una fecha a partir de la cual dejan de publicarse parches.
También puedes consultar nuestro análisis detallado del calendario y las repercusiones del fin de vida útil (EOL) de Node.js 18 en nuestra guía específica.
Qué supone el fin de la vida útil (EOL) de Node.js para tus aplicaciones
El proyecto Node.js es inusualmente directo al respecto. Su propia página de «fin de vida útil» advierte de cuatro consecuencias: el cese de las correcciones de vulnerabilidades, la incompatibilidad de las herramientas de desarrollo, la deriva del ecosistema a medida que los paquetes más populares dejan de dar soporte a los entornos de ejecución antiguos, y problemas de cumplimiento normativo, ya que «muchas auditorías del sector prohíben el uso de entornos de ejecución sin mantenimiento».
Las vulnerabilidades CVE sin parchear que ya conoces
Node.js publica actualizaciones de seguridad de forma periódica, y en cada una de ellas se omiten por completo las líneas relacionadas con el fin de vida útil (EOL). A fecha de 30 de julio de 2026, la página de fin de vida útil del proyecto recoge 27 vulnerabilidades de alta gravedad en Node.js 20 y 15 en Node.js 18, y estas cifras no hacen más que aumentar.
Lo que hace que esto sea peligroso es el patrón. La versión de seguridad del 29 de julio de 2026 se aplicó únicamente a las líneas 26.x, 24.x y 22.x. Solucionó once problemas, tres de ellos de gravedad alta, incluido un error de reentrada en HTTP/2 en el nghttp2 integrado que deja al proceso con un uso después de liberación (use-after-free) en el montón. Node.js 20 y 18 no recibieron ninguna corrección, y el aviso indicaba a los atacantes exactamente dónde buscar en cada versión que no había recibido la corrección. Aviso público, parche público, comparación pública. La mayor parte del trabajo de detección ya está hecho.
Para hacerte una idea de cómo es una vulnerabilidad grave, fíjate en el «HTTP/2 Rapid Reset» (CVE-2023-44487). Se aprovechó como vulnerabilidad de día cero para lanzar los mayores ataques DDoS jamás registrados hasta ese momento, y afectó a todos los servidores Node.js que tenían HTTP/2 habilitado. Las versiones 18 y 20 de Node.js recibieron parches en cuestión de días. Si la misma vulnerabilidad se descubriera hoy, ninguna de esas dos versiones recibiría jamás una corrección por parte del proyecto Node.js.
Las vulnerabilidades CVE que nunca se corregirán
El equipo de seguridad de Node.js no evalúa ni corrige vulnerabilidades en las versiones que han llegado al final de su vida útil (EOL). En enero de 2025, el proyecto intentó hacer esto visible para los escáneres de vulnerabilidades mediante la publicación de CVE-2025-23087, un CVE general que abarca Node.js 17 y todas las versiones anteriores, con CVE complementarios para las versiones 19 y 21. El Programa CVE rechazó los tres. La política de sustitución es más amplia: ahora, cada nuevo CVE de Node.js cubre de forma predeterminada las líneas de versiones al final de su vida útil (EOL), a menos que el proyecto disponga de información específica que indique que no se aplica a alguna de ellas.
Por lo tanto, las versiones 18 y 20 de Node.js no se mencionan expresamente en ningún aviso general de fin de vida útil (EOL), por lo que se presume que se ven afectadas por todos los avisos posteriores. La razón aducida por el proyecto es la falta de recursos: con más de veinte versiones en fin de vida útil, cada una con diferentes dependencias y procesos de compilación, y vulnerabilidades que se manifiestan de forma distinta en función de componentes como OpenSSL, no es viable realizar una evaluación exhaustiva. Cualquier problema que se detecte en ellas queda sin evaluar y sin corregir.
Señales de alerta en materia de cumplimiento normativo
Los auditores llegan a la misma conclusión por una vía diferente. PCI DSS 4.x El requisito 6.3.3 exige que los parches para las vulnerabilidades críticas, identificadas a través de su propio proceso de clasificación de riesgos, se instalen en el plazo de un mes desde su publicación, algo que ningún proceso puede cumplir cuando no existe ningún parche. Los criterios de seguridad de SOC 2 asumen un proceso de gestión de vulnerabilidades, y el software sin fuente de parches dificulta demostrarlo. En el caso de las cargas de trabajo federales y reguladas, un entorno de ejecución sin mantenimiento puede constituir un hallazgo por sí mismo, antes incluso de que alguien pregunte por CVE concretos.
El riesgo oculto: el árbol de dependencias integradas de Node.js
Esto es lo que sorprende incluso a los equipos con más experiencia: Node.js no es solo Node.js. La documentación de dependencias enumera 30 componentes en su árbol de código fuente, y aproximadamente 25 de ellos se incluyen en cada binario oficial de Node.js. Entre ellos se incluyen el motor de JavaScript V8, el bucle de eventos libuv, el analizador HTTP llhttp, el cliente HTTP undici, nghttp2, nghttp3 y ngtcp2 para HTTP/2 y HTTP/3, el resolutor de DNS c-ares, zlib, brotli y zstd para la compresión, ICU, SQLite, el propio npm y la copia de OpenSSL de Node. (El conjunto exacto varía según la versión principal; por ejemplo, Node.js 18 y 20 son anteriores a la inclusión de SQLite y zstd).
Esos componentes se dividen en dos grupos, y ambos suponen un problema tras el fin de vida útil (EOL). Aproximadamente la mitad también existen como bibliotecas del sistema: OpenSSL, zlib, SQLite, ICU, nghttp2, c-ares y libuv. Tu sistema operativo aplica parches a esos componentes en otras partes del sistema, pero los binarios oficiales de Node.js —los de nodejs.org, los de gestores de versiones como nvm y las imágenes estándar de Docker— se compilan en sus propias copias, y las actualizaciones del sistema operativo nunca les llegan. (Algunos paquetes de distribuciones de Linux se vinculan a unas pocas bibliotecas del sistema, pero eso es la excepción). La otra mitad, que incluye V8, llhttp, undici y npm, se mantiene en el proyecto original, pero no tiene ningún paquete del sistema en ninguna parte de tu máquina, por lo que una corrección en el proyecto original solo te llega cuando una nueva compilación de Node.js la incluye. En cualquier caso, la conclusión es idéntica: las correcciones te llegan a través de una nueva compilación de Node.js o no te llegan en absoluto, y cuando una línea de versiones llega al fin de su vida útil (EOL), todo el árbol se congela al completo.
No se trata de una vulnerabilidad teórica. «Rapid Reset» era una vulnerabilidad a nivel del protocolo HTTP/2 que Node.js solucionó a través de su biblioteca integrada nghttp2, y no en el código escrito por el equipo de Node.js. La versión de seguridad de julio de 2026 incluyó actualizaciones de undici y llhttp, además de las propias correcciones de Node.js. En una versión compatible, estas se instalan automáticamente. En una versión al final de su ciclo de vida (EOL), cada uno de esos componentes acumula silenciosamente los CVE de origen que le sean aplicables, sin que exista una vía de distribución para las correcciones.
Cualquier opción seria de soporte prolongado debe abarcar toda esta superficie, por lo que el servicio «Endless Lifecycle Support» (ELS) de TuxCare aplica parches al árbol de dependencias incluido, y no solo al núcleo de Node.js.
Tus opciones tras el fin de la vida útil de Node.js
Hay tres vías posibles, y la más adecuada depende del nivel de riesgo migratorio que puedas asumir en este momento:
- ¿No puedes actualizar este trimestre, pero necesitas mantenerte al día con los parches? Soporte ampliado.
- ¿Dispones de tiempo para el desarrollo y de una cadena de dependencias compatible? Actualiza a una versión LTS compatible.
- ¿Node.js es una parte pequeña o cada vez más reducida de tu pila tecnológica? Plantéate migrar fuera de Node.js ya que estás en ello.
Utiliza el soporte técnico de ciclo de vida ilimitado para Node.js
La forma más rápida de eliminar el riesgo inmediato sin tener que modificar el código es aplicar parches proporcionados por el proveedor. El servicio ELS de TuxCare para Node.js ofrece correcciones de seguridad continuas para Node.js 12, 14, 16, 18 y 20: los parches se adaptan desde el código original, se comprueba su integridad y se realizan pruebas de regresión, se firman, están respaldados por un SLA y se distribuyen a través de los gestores de paquetes que ya utilizas. TuxCare ofrece este servicio como socio del Programa de Sostenibilidad del Ecosistema de la Fundación OpenJS, y figura como proveedor de soporte comercial en la propia página de fin de vida útil (EOL) del proyecto Node.js.
La cobertura incluye el árbol de dependencias integrado descrito anteriormente, desde OpenSSL hasta undici, sin coste adicional. Puedes consultar en tiempo real las vulnerabilidades y las correcciones de Node.js en el TuxCare CVE Tracker para ver exactamente qué se está corrigiendo.
Para que quede claro el papel que desempeña: es un puente, no un destino. ELS te devuelve lo que EOL te quita: tiempo para planificar una actualización según tus propios términos, en lugar de hacerlo bajo la presión de un incumplimiento o una auditoría.
Actualizar a una versión LTS compatible
La solución más adecuada a largo plazo. Node.js 24 incorpora años de trabajo en el rendimiento, las últimas funciones de V8 y soporte hasta el 30 de abril de 2028. Node.js 22 también sigue recibiendo soporte, pero solo hasta el 30 de abril de 2027, lo que lo convierte en una etapa intermedia más que en un destino final. Si tu árbol de dependencias está en buen estado y tu cobertura de pruebas es adecuada, dar un salto de una versión principal suele ser factible.
Sin embargo, el esfuerzo aumenta en función de la distancia y la complejidad del código. Cada versión principal conlleva cambios que rompen la compatibilidad, los complementos nativos deben recompilarse según la nueva ABI y es posible que los paquetes fijados hace años no tengan una versión compatible. Pasar de la 18 a la 24 no es una sola migración, sino tres que se superponen unas a otras.
Migrar a otra tecnología
Si un servicio tiene que reescribirse de todos modos, el fin de vida útil (EOL) puede ser el detonante para consolidarlo en lo que tu organización considere estratégico en ese momento, ya sea otro entorno de ejecución como Deno o Bun, o un lenguaje completamente diferente. Esa flexibilidad es real, pero también lo es el coste: una migración puede suponer reescribir gran parte del funcionamiento del servicio, con toda la carga que ello conlleva en cuanto a pruebas. Rara vez tiene sentido como respuesta exclusiva al fin de vida útil.
Los riesgos de precipitarse al realizar una actualización
Una actualización a una versión principal de Node.js es un proyecto, no una simple actualización de dependencias. Implica adaptar el código a cambios en la API que rompen la compatibilidad, verificar la compatibilidad en todo el archivo de bloqueo, recompilar los módulos nativos, actualizar las imágenes de CI, los archivos Dockerfile y las cadenas de herramientas de compilación, y realizar pruebas de regresión en todo lo que afecta al entorno de ejecución.
Los equipos que condensan ese trabajo en una situación de emergencia —normalmente porque una auditoría o una vulnerabilidad CVE revelada les obliga a ello— suelen pagarlo más adelante: inestabilidad en producción debido a rutas insuficientemente probadas, un aumento repentino de la carga de soporte técnico, soluciones provisionales que se consolidan y se convierten en deuda técnica, y costes imprevistos precisamente donde el presupuesto no los había previsto. Este patrón se repite con tanta frecuencia que evitar el escenario de actualización forzada es, en sí mismo, una estrategia de seguridad. La presión de los plazos y una ingeniería meticulosa no son compatibles.
Protege Node.js más allá de su fin de vida útil con TuxCare
TuxCare lleva más de una década desarrollando la metodología que sustenta la aplicación de parches para vulnerabilidades a nivel empresarial y, en la actualidad, ofrece soluciones retrocompatibles a más de 2.300 clientes empresariales de los sectores de servicios financieros, telecomunicaciones, sanidad y administración pública. El proceso de aplicación de parches combina la supervisión automatizada de vulnerabilidades, la evaluación de parches y la adaptación retrospectiva con la validación por parte de expertos, y cada versión se compila a partir de fuentes verificadas y firmadas, con certificados que avalan sus dependencias.
En el caso de Node.js, esto se traduce en la aplicación continua de parches de seguridad, estabilidad y pruebas de auditoría para las versiones en las que realmente se ejecutan tus aplicaciones: cobertura de las dependencias incluidas, correcciones proporcionadas a través de tus gestores de paquetes existentes y un precio que supone una fracción del coste de una migración no planificada. Descubre ELS para Node.js, o empieza con el CVE Tracker para consultar en tiempo real las vulnerabilidades y correcciones de Node.js.
