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
- Una vez que una versión de Node.js llega al final de su ciclo de vida, el desarrollador original deja de comprobar si hay nuevas vulnerabilidades que la afecten.
- A partir de Node.js 27, el proyecto lanza una versión principal al año, y cada línea de versiones pasa a ser LTS.
- Las herramientas de IA están detectando errores reales en Node.js, pero los informes duplicados están desbordando ahora a los voluntarios que se encargan de la clasificación.
- Los equipos que no puedan actualizar según lo previsto necesitan un entorno de ejecución parcheado, no esperar a que no se filtre nada.
Una aplicación de Node.js no deja de funcionar cuando su versión llega al final de su ciclo de vida. El proyecto original simplemente deja de ocuparse de ella. Y, tal y como explicó James Snell, miembro del Comité Directivo Técnico de Node.js, en una reciente charla informal con TuxCare, esa diferencia es mucho mayor de lo que parece.
«Ni retrocompatibilidad, ni correcciones», afirmó. Cuando se recibe un nuevo informe sobre una vulnerabilidad, el equipo ni siquiera comprueba si afecta a una línea de producto al final de su ciclo de vida. Un servicio puede parecer perfectamente operativo en producción, mientras que el trabajo de seguridad que se lleva a cabo en las fases iniciales ha avanzado discretamente sin tenerlo en cuenta.
Ese fue uno de los varios momentos espontáneos de «Keepers of the Runtime», donde Snell conversó con Chris DeMars, promotor sénior de desarrolladores de TuxCare. Sin diapositivas ni demostraciones de productos. Hablaron de por qué Node.js está pasando a lanzar una versión principal al año, cómo están afectando los informes de seguridad generados por IA a un equipo de seguridad formado por voluntarios y cuánto trabajo humano hay detrás de una actualización de seguridad que parece rutinaria. Esto es lo más importante si utilizas Node.js en producción, aunque merece la pena dedicar media hora a ver la grabación completa.
El fin de la vida útil de Node.js supone el fin del trabajo de seguridad en el código fuente
La descripción que hizo Snell del «fin de vida útil» fue contundente. Una vez que una versión principal deja de recibir soporte, no se le aplica nada más. Ni correcciones de seguridad, ni correcciones de errores habituales, ni adaptaciones de ramas más recientes. «Puede que otros lo hagan, pero nosotros no», afirmó al referirse a la comprobación de versiones antiguas ante nuevos informes. «Una vez que llega al fin de vida útil, deja de estar en nuestro radar».
Las propias directrices del proyecto sobre las vulnerabilidades de los productos al final de su ciclo de vida (EOL) siguen la misma línea. Es muy posible que una versión antigua se vea afectada por una vulnerabilidad revelada en una versión que sigue recibiendo mantenimiento, pero el equipo de desarrollo original no suele investigar la rama antigua para confirmar el impacto, y mucho menos desarrollar una corrección.
Piensa en lo que eso significa para tu escáner. Desde 2025, las nuevas CVE de Node.js incluyen las líneas EOL como afectadas por defecto, a menos que el proyecto indique lo contrario. Eso hace que la advertencia siga visible, pero nadie del equipo de desarrollo original ha confirmado el fallo en tu versión, ni nadie del equipo de desarrollo original está trabajando en la corrección.
Un entorno de ejecución EOL tampoco funciona de forma aislada. Node.js incluye componentes como V8 y OpenSSL, y Snell señaló que constantemente surgen vulnerabilidades de día cero en V8, incluidas las que permiten escapar del entorno de pruebas. No todas las vulnerabilidades de V8 del lado del navegador llegan a Node.js, pero alguien tiene que averiguar cuáles sí lo hacen, y en una línea EOL esa persona no es el desarrollador original. Mientras tanto, las bibliotecas y las herramientas siguen dejando de dar soporte a las versiones más antiguas de Node.js, por lo que posponer una actualización se vuelve más difícil cada mes.
Nada de esto significa que todas las implementaciones en fin de vida útil (EOL) sean automáticamente vulnerables. La exposición depende de la vulnerabilidad concreta, la configuración y las rutas de código accesibles. Lo que cambia al llegar al fin de vida útil es que dejan de llegar respuestas y parches del desarrollador original, lo que obliga a tu equipo a investigar más precisamente en el momento en que sus opciones se están reduciendo.
Por qué Upstream no mantendrá activas las versiones antiguas durante más tiempo
La gente sí que pide a los responsables del proyecto que mantengan una versión antigua en funcionamiento un poco más. La respuesta tiene que ver con las personas y las máquinas. Node.js lo mantienen principalmente voluntarios. Algunos colaboradores cuentan con patrocinio, pero, según explica Snell, casi todos los que lanzan versiones, realizan retroportes y contribuyen lo hacen en su tiempo libre. «No vamos a seguir dando soporte a todo de forma generalizada para siempre», afirmó Snell. «No podemos. Es imposible».
Luego está la CI. Según Snell, una ejecución completa de CI abarca unas 55 combinaciones de plataformas, arquitecturas y sistemas operativos, con unas 7.800 pruebas en cada una, y una sola ejecución puede tardar hasta una hora. Las empresas donan esa infraestructura, y su capacidad es fija. Si multiplicamos eso por cada línea de versiones antiguas, las cuentas dejan de cuadrar rápidamente. Como dijo Snell: «El fin de la vida útil es el fin de la vida útil porque, sencillamente, no podemos dedicar físicamente los recursos necesarios para mantenerla».
Es una postura razonable; es difícil rebatirla. Sin embargo, deja un vacío, y ese vacío recae sobre quienquiera que siga utilizando la versión antigua.
Por qué Node.js va a pasar a lanzar una versión principal al año
Ese mismo problema de capacidad explica el nuevo calendario de lanzamientos. El antiguo calendario era un compromiso alcanzado durante la reunificación de io.js: versiones impares de corta duración, con soporte técnico durante solo unos ocho meses, para que los autores de bibliotecas y marcos de trabajo pudieran anticipar las novedades, además de versiones pares que pasaban a ser LTS (soporte a largo plazo) para las empresas.
Los datos de descargas de los últimos diez años revelaban una realidad muy distinta. «En realidad, nadie utilizaba las versiones a corto plazo», afirmó Snell. Las empresas ya actualizaban el software aproximadamente una vez al año, si acaso. Por su parte, los responsables del mantenimiento a veces tenían que gestionar cuatro o cinco líneas de lanzamiento activas a la vez, y cada corrección de seguridad debía rastrearse a través de ramas que habían evolucionado de formas diferentes.
Según el plan oficial de lanzamientos de Node.js, Node.js 27 es la primera versión del nuevo modelo. Cada año se lanza una versión principal en abril, que pasa a ser LTS en octubre, por lo que todas las líneas de versiones acaban siendo LTS. El canal Alpha asume la función de pruebas tempranas que antes desempeñaban las versiones impares y, tras seis meses en Alpha, cada línea recibe 36 meses de soporte desde su primera versión «Current» hasta el final de su ciclo de vida. El resumen de Snell sobre las ventajas fue sencillo: hay que gestionar muchas menos líneas, con unas tres activas a la vez.
| Línea de lanzamiento | Comienza la fase alfa | Primera publicación | Entra en LTS | Fin de la vida |
|---|---|---|---|---|
| Node.js 26 (la última versión basada en el modelo anterior) | No aplicable | May 2026 | Octubre 2026 | Abril 2029 |
| Node.js 27 | Octubre 2026 | Abril 2027 | Octubre 2027 | Abril 2030 |
| Node.js 28 | Octubre 2027 | Abril 2028 | Octubre 2028 | Abril 2031 |
Si tu equipo ya solo implementa versiones LTS, apenas habrá cambios más allá de la numeración de versiones. Si desarrollas productos con Node.js, el consejo de Snell era dejar de esperar a abril para descubrir qué es lo que ha dejado de funcionar. Los cambios importantes y las funciones obsoletas se publican en main de forma constante. Añade una tarea de prueba de funcionamiento en la integración continua (CI) que se ejecute con las próximas versiones alfa sin bloquear las fusiones, y asegúrate de que alguien revise realmente los resultados. Las versiones alfa no están pensadas para producción, pero detectar un problema con tres o cuatro meses de antelación resulta mucho más económico que descubrirlo durante un periodo de migración.
¿Qué ocurre entre un informe de seguridad de Node.js y la aplicación de una corrección?
Node.js recibe los informes de vulnerabilidades a través de HackerOne. Un evaluador determina primero si el comportamiento es real y, a continuación, decide si traspasa un límite de seguridad definido por el modelo de amenazas del proyecto.
Es fácil pasar por alto esa segunda criterio. El modelo de confianza de Node es tajante: si el código se ejecuta, se considera de confianza. Un error de segmento que solo se puede provocar ejecutando tu propio código de forma local es probablemente un error común, que se corrige de forma abierta. Cualquier cosa a la que se pueda acceder a través de una entrada remota no fiable, como la ejecución remota de código o una denegación de servicio remota, se trata como una vulnerabilidad.
Esas correcciones se desarrollan, revisan e incorporan en una bifurcación privada de Node, y la versión de seguridad se genera a partir de ahí. Solo después de su lanzamiento, los cambios pasan al repositorio público. Esto mantiene el intervalo entre la divulgación y la disponibilidad del parche cercano a cero para las líneas con soporte, pero también significa que el reloj ya empieza a correr para ti en el momento en que se hace público un aviso. La versión del 21 de octubre de 2026 es un buen ejemplo: diez CVE en las líneas 22.x, 24.x y 26.x, cuatro de ellas clasificadas como de riesgo alto. El artículo de TuxCare «10 CVE de Node.js, un RCE en Brotli y qué hacer si tu versión está al final de su ciclo de vida» desglosa lo que esto significa para cualquiera que utilice una línea al final de su ciclo de vida. La siguiente ronda ya está programada. Node.js ha anunciado otra actualización de seguridad para el 11 de noviembre de 2026, o poco después, que volverá a abarcar las versiones 22.x, 24.x y 26.x, con el problema más grave clasificado como «alto». El aviso deja claro que las versiones al final de su ciclo de vida (EOL) siempre se ven afectadas cuando se produce una actualización de seguridad.
La IA está detectando errores reales y saturando la cola de clasificación
Fue en este punto donde Snell se mostró más entusiasmado. El escaneo asistido por IA funciona. «Sin duda alguna, está detectando errores reales», afirmó. La precisión no es el principal problema. Lo es el volumen.
Los investigadores que utilizan herramientas similares suelen encontrar el mismo error al mismo tiempo y notificarlo de forma independiente. Snell explicó que recibía entre 10 y 20 informes sobre un mismo problema, a los que se sumaban otros mientras se trabajaba en la corrección, y que seguían llegando de forma esporádica mucho tiempo después de la divulgación. Durante un periodo reciente de clasificación de incidencias, estimó que «probablemente nueve de cada diez informes eran duplicados», una estimación basada en ese volumen de trabajo, no en una tasa calculada.
La actualización de seguridad del segundo trimestre de 2026 de la Fundación OpenJS corrobora esta tendencia. Node.js recibió 352 informes de HackerOne en los dos años anteriores a ese trimestre. Posteriormente, los informes se multiplicaron por 4,6 en febrero de 2026 tras la llegada de las herramientas de análisis asistidas por IA, y solo en marzo se registraron 65. En el momento de la charla, según Snell, Node.js ya había publicado correcciones para más de 50 vulnerabilidades en 2026, todo un récord.
Su consejo para los investigadores fue muy práctico. Lee la política de seguridad y el modelo de amenazas del proyecto. Busca en los informes publicados por HackerOne para comprobar si el problema ya se ha solucionado. Y si tu agente encuentra 20 posibles incidencias, no envíes 20 informes de golpe. Clasifícalas y envía primero las más críticas.
El trabajo que no aparece en las notas de la versión
Snell no llegó a Node.js gracias a ningún gran plan. En 2013, mientras trabajaba en IBM, descubrió un error por el que Node interpretaba un método HTTP distorsionado como P?T como un método válido, en lugar de rechazarlo. Al no existir aún ningún proceso de notificación de fallos de seguridad, abrió una incidencia pública, le dijeron que no entendía cómo funcionaba ese tipo de software, lo arregló él mismo y se marchó. La bifurcación de io.js lo trajo de vuelta cuando IBM necesitaba un responsable técnico para todo lo relacionado con Node, y se incorporó al TSC alrededor de marzo de 2015.
El trabajo diario es menos glamuroso de lo que sugiere el título. Las mañanas empiezan con una hora o más de notificaciones de GitHub, a veces hasta 800 o 900 al día. La revisión de código le lleva aún más tiempo. «Leo cada línea de cada solicitud de incorporación de cambios, incluso las más extensas», afirma, ya sean diez líneas o 20 000, a menudo en dos o tres pasadas. La inteligencia artificial escribe ahora la mayor parte de sus pruebas, pero no ha sustituido al criterio humano.
Snell también rechazó la idea de que Node.js tenga una hoja de ruta de producto. «No hay ningún gestor de producto. Ni siquiera hay un gestor de proyectos». Nadie puede «comprar» una funcionalidad en Node. Una vez superada la integración continua (CI), una solicitud de incorporación de cambios (pull request) puede incorporarse con dos aprobaciones tras un mínimo de 48 horas, o con una sola aprobación tras una semana, siempre que nadie se oponga. Así que, si quieres que Node haga algo, su consejo es que abras una solicitud de incorporación de cambios y lo hagas tú mismo, en lugar de exigir que los voluntarios lo desarrollen de forma gratuita.
Qué significa esto para los equipos que aún utilizan versiones antiguas de Node.js
Empieza por lo que realmente está implementado. No por lo que dice el Dockerfile actual ni por lo que indica el ticket de migración, sino por las versiones de Node.js que se están ejecutando en producción, incluidos los servicios que nadie ha tocado desde hace tiempo. Compáralas con el calendario de lanzamientos de Node.js, marca aquellas que ya hayan superado su fin de vida útil (EOL) y asigna un responsable a cada una. Node.js 20 llegó al fin de su vida útil el 30 de abril de 2026, y Node.js 22 lo hará en abril de 2027, por lo que esto no es solo un problema para los equipos que utilizan versiones muy antiguas.
Si puedes actualizar ahora, hazlo. Una versión LTS con soporte técnico es la solución más limpia, y las actualizaciones rutinarias en tiempo de ejecución son mejores que tener que hacer una actualización de emergencia cada pocos años.
Hay aplicaciones que no pueden ajustarse a ese calendario. Imagina un servicio de pagos que depende de Node.js 18 porque un complemento nativo deja de funcionar en las versiones más recientes de V8, y la migración está pendiente de que el proveedor lo reescriba, lo cual tardará dos trimestres. En casos como ese, «lo actualizaremos más adelante» no es un plan de seguridad, a menos que el antiguo entorno de ejecución siga teniendo alguna forma de recibir parches.
Esa es la laguna que cubre el servicio «Endless Lifecycle Support» (ELS) de TuxCare para Node.js. Como parte del ELS para entornos de ejecución, incorpora retroactivamente correcciones de seguridad en las versiones de Node.js fuera de ciclo de vida (EOL) cubiertas por el SLA y las distribuye como actualizaciones de paquetes, de modo que tus aplicaciones sigan funcionando en el entorno de ejecución para el que fueron creadas mientras completas la migración según tu calendario. Basta con reiniciar los procesos de Node.js afectados tras una actualización para que utilicen el entorno de ejecución parcheado. La cobertura se remonta hasta Node.js 10 en Enterprise Linux y abarca también Ubuntu, Debian y Alpine Linux, aunque las versiones compatibles varían según el sistema operativo, por lo que te recomendamos consultar la matriz de versiones en la documentación. Esto no elimina la necesidad de actualizar en algún momento. Cubre el periodo comprendido entre el día en que el desarrollador original deja de corregir una versión y el día en que puedes retirarla de forma segura.
Tampoco hace falta esperar a que te llamen del departamento de ventas. Compra ELS para Runtimes por Internet, instálalo y vuelve a incorporar tus versiones de Node.js al final de su ciclo de vida (EOL) a una línea de parches.
Preguntas frecuentes
¿Qué ocurre cuando una versión de Node.js llega al final de su ciclo de vida?
Upstream detiene todas las incorporaciones a esa rama, incluidas las correcciones de seguridad, y no comprueba si las vulnerabilidades recién detectadas la afectan. A partir de ese momento, el riesgo recae en el equipo que la gestiona.
¿Cuándo sale Node.js 27?
La versión alfa de Node.js 27 se lanzó en octubre de 2026. El primer lanzamiento de la versión «Current» está previsto para abril de 2027, con la promoción a LTS en octubre de 2027 y el fin de su vida útil en abril de 2030.
¿Se puede seguir utilizando Node.js 18 o Node.js 20 una vez finalizado su ciclo de vida?
Sí. Los servicios de soporte comercial, como el «Endless Lifecycle Support for Node.js» de TuxCare, siguen proporcionando correcciones de seguridad para las versiones en fin de vida útil (EOL) cubiertas mientras planificas tu actualización, siempre y cuando instales las actualizaciones y reinicies los procesos afectados.
Mira la charla informal completa
La grabación incluye las historias que no se han incluido en esta publicación, además de la sesión de preguntas y respuestas en directo sobre los informes duplicados y la retención de voluntarios. No te pierdas «Keepers of the Runtime» con James Snell y Chris DeMars.
Y si parte de tu pila sigue utilizando una versión de Node.js para la que el desarrollador original ya ha dejado de ofrecer parches, no esperes a que el próximo aviso de seguridad tome la decisión por ti. Contrata ELS for Runtimes y asegúrate de que las versiones cubiertas sigan recibiendo parches de seguridad mientras realizas la actualización a tu ritmo.
