Actualización de seguridad de Node.js del 11 de noviembre y correcciones de la versión al final de su vida útil

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

Se están preparando las compilaciones de ELS para la versión de noviembre de Node.js; las correcciones están previstas para el día del lanzamiento

Se espera que el 11 de noviembre, poco después del lanzamiento de la versión original, estén disponibles las compilaciones corregidas para todas las líneas de Node.js afectadas en los repositorios de CloudLinux y TuxCare, incluidas las versiones fuera de soporte.

Estado de ELS para tiempos de ejecución: El equipo tiene previsto publicar todas las versiones afectadas de una sola vez el mismo día que se lance la actualización de seguridad de Node.js, incluyendo Node.js 22, 24 y 26, junto con las versiones que han llegado al final de su ciclo de vida: 10, 12, 14, 16, 18, 19, 20 y 23. Las actualizaciones se distribuyen a través del mismo yum, apto apk flujo de trabajo que ya se está utilizando, y las compilaciones se instalan en /opt/alt/ junto a cualquier otra versión de Node.js que haya en el servidor. Planifica un reinicio de todos los procesos de Node.js una vez instalado el paquete.

Descargar ELS para Runtimes →

Principales conclusiones

Node.js tiene previsto lanzar correcciones de alta gravedad para las versiones 22.x, 24.x y 26.x el 11 de noviembre o poco después.
Upstream considera que las versiones al final de su ciclo de vida se ven afectadas, pero no ofrece soluciones para ellas.
ELS for Runtimes está preparando correcciones retroactivas para ocho versiones de Node.js que han llegado al final de su ciclo de vida en todas las distribuciones compatibles.
Reinicia todas las aplicaciones de Node.js tras la actualización y comprueba las adaptaciones de versiones obsoleta por versión del paquete, no node --version.

Node.js ha programado su próxima ronda de lanzamientos de seguridad para el miércoles 11 de noviembre de 2026, o poco después. Se avecinan nuevas versiones para las líneas 22.x, 24.x y 26.x, y el proyecto califica el problema más grave de cada línea como «alto». Los identificadores CVE y los detalles técnicos se mantienen en secreto hasta que se publiquen los lanzamientos, por lo que cualquier afirmación prematura sobre métodos de ataque específicos debe tomarse con bastante recelo.

Para los equipos que ejecutan Node.js a través de alt-nodejs En el caso de los paquetes, el anuncio es solo la mitad de la historia. Esto incluye los servidores de alojamiento CloudLinux, así como los servidores Debian, Ubuntu, Alpine y Enterprise Linux cubiertos por el servicio Endless Lifecycle Support (ELS) de TuxCare para Node.js. Una corrección publicada en nodejs.org no, por sí sola, aplica ningún parche a lo que se esté ejecutando en esos sistemas. Los paquetes actualizados deben compilarse, publicarse e instalarse, y las aplicaciones en ejecución deben reiniciarse antes de que la corrección surta efecto. La mayor parte del trabajo preparatorio puede realizarse ahora, mucho antes de que se den a conocer los detalles.

Las líneas de fin de vida situadas aguas arriba no se pueden reparar

La versión de origen solo abarca las versiones 22, 24 y 26. El aviso de Node.js indica que las versiones fuera de soporte siempre se ven afectadas cuando se publica una actualización de seguridad, aunque el desarrollador original ya no ofrezca correcciones para ellas. Eso no significa que todas las versiones antiguas incluyan todos los errores recién corregidos, pero ninguna instalación que utilice Node.js 20, 18 o versiones anteriores debería considerarse segura solo porque su versión no figure en la lista de versiones actualizadas.

Esa laguna es precisamente lo que cubre el servicio ELS para Runtimes. El equipo de ELS de TuxCare está preparando correcciones retrocompatibles para ocho productos que han llegado al final de su ciclo de vida alt-nodejs líneas, Node.js 10, 12, 14, 16, 18, 19, 20 y 23, de modo que una aplicación fijada a un entorno de ejecución más antiguo pueda incorporar las correcciones de esta ronda mediante una actualización del paquete, en lugar de tener que realizar una migración de emergencia. El retroportado supone un auténtico trabajo de ingeniería —la corrección debe adaptarse a código que el proyecto original ya no mantiene—, pero el plan es lanzar estas compilaciones el 11 de noviembre junto con el resto, poco después del lanzamiento del proyecto original. El Documentación de ELS para Runtimes enumera las versiones de Node.js compatibles con cada sistema operativo.

¿Qué repositorios contienen las compilaciones corregidas?

En CloudLinux, Node.js Selector se ejecuta en alt-nodejs paquetes, y la versión de Node.js se selecciona por aplicación, no por servidor ni siquiera por cuenta. Así es como un servidor de alojamiento acaba ejecutando, sin que nadie se dé cuenta, tres o cuatro versiones de Node.js a la vez, incluidas algunas que ya no cuentan con soporte por parte del desarrollador original.

Lo mismo alt-nodejs Los paquetes también se distribuyen a través de los repositorios de TuxCare para los clientes de ELS, y abarcan desde Debian 10 hasta 13, desde Ubuntu 18.04 hasta 26.04 y Alpine 3.23 y 3.24, además de versiones firmadas por TuxCare para Enterprise Linux. Se instalan en /opt/alt/, junto con la versión de Node.js que ya incluya la distribución, y actualizarla como de costumbre yum, apto apk flujo de trabajo. Las versiones de Node.js 23 solo están disponibles en Debian 12, Debian 13 y Alpine.

¿Cuándo estarán disponibles los paquetes actualizados?

CloudLinux tiene previsto comenzar a desarrollar tan pronto como Node.js publique las correcciones y espera lanzar la versión actualizada alt-nodejs paquetes más tarde ese mismo día. Esto abarca las versiones 22, 24 y 26, junto con las líneas que han llegado al final de su ciclo de vida en todas las versiones de CloudLinux, desde la 6 hasta la 10, y las compilaciones del repositorio de TuxCare se publican en la misma tanda. Ese plan depende del lanzamiento de la fuente, por lo que se trata de un objetivo y no de un plazo de entrega fijo.

Los servidores con CloudLinux cuentan con otros dos tipos de paquetes de Node.js con sus propias rutas de actualización. En los servidores con cPanel que ejecutan CloudLinux 8, ea-nodejs22 también procede de los repositorios de CloudLinux, pero se compila a partir del paquete de cPanel. Su corrección depende de que cPanel publique primero una versión actualizada y de que, a continuación, CloudLinux ponga a disposición el paquete correspondiente. El nativo del sistema operativo nodejs Los paquetes vuelven a seguir una ruta independiente, a través de las actualizaciones habituales de los sistemas operativos basados en RHEL y AlmaLinux. Cualquier entorno de ejecución instalado fuera de estos canales debe comprobarse por separado, ya que un alt-nodejs La actualización no lo modificará.

Tareas preparatorias que conviene hacer antes del miércoles

En CloudLinux, suscríbete a la página de estado de CloudLinux para esta versión. CloudLinux tiene previsto comunicar una hora estimada de llegada a primera hora del martes 10 de noviembre y, a continuación, publicar actualizaciones sobre el progreso cada pocas horas hasta que los paquetes estén disponibles. Los clientes de ELS que utilicen otras distribuciones pueden estar atentos a las versiones corregidas en la lista de correcciones disponibles para Node.js de TuxCare.

A continuación, comprueba qué tienes. Ejecuta la opción que corresponda al gestor de paquetes del sistema (RPM, DEB o APK):

rpm -qa 'alt-nodejs*'
dpkg -l 'alt-nodejs*'
apk info | grep alt-nodejs

Esto muestra qué versiones están instaladas, no qué aplicaciones las utilizan. En CloudLinux, comprueba también Node.js Selector para ver la versión asignada a cada aplicación. En otros entornos, las unidades de systemd, las configuraciones de PM2 y las imágenes de contenedor pueden apuntar cada una a un binario diferente, así que comprueba también esos elementos. Una sola aplicación que se haya pasado por alto durante el periodo de actualización puede seguir ejecutándose con un entorno de ejecución antiguo, mientras que todo lo demás parece estar actualizado.

A continuación, planifica los reinicios, ya que la actualización del paquete por sí sola no es suficiente. Al instalar un paquete actualizado se sustituye el binario del disco, pero una aplicación de Node.js en ejecución sigue utilizando el antiguo hasta que se reinicia, independientemente de lo que indique el gestor de paquetes.

Las aplicaciones gestionadas a través de Node.js Selector se pueden reiniciar desde su interfaz o con este comando, utilizando el nombre de la cuenta y la ruta raíz de la aplicación:

cloudlinux-selector restart --json --interpreter nodejs --user <user> --app-root <app_root>

Cualquier proceso que se ejecute fuera de Node.js Selector se reinicia siguiendo el procedimiento habitual de gestión de ese servicio. A continuación, se muestra una lista de todos los procesos de Node.js en ejecución con su hora de inicio, por lo que se pueden identificar fácilmente aquellos que se iniciaron antes de la actualización:

ps -eo pid,lstart,args | grep -E '[n]ode( |$)'

En los servidores que alojan numerosas aplicaciones, hay que determinar con antelación el orden de reinicio y coordinarse con los responsables de las aplicaciones cuando el tiempo de inactividad sea importante. Un reinicio planificado y escalonado es mejor que uno apresurado la noche del lanzamiento.

Qué hacer una vez que lleguen los paquetes

Cuando el correspondiente alt-nodejs Los paquetes ya están disponibles; instálalos siguiendo tu proceso habitual de gestión de paquetes y reinicia las aplicaciones afectadas. A continuación, comprueba que cada aplicación se haya reiniciado correctamente y que esté ejecutando el entorno de ejecución actualizado. El hecho de que la instalación de los paquetes se haya realizado correctamente no garantiza que todas las aplicaciones hayan incorporado la corrección.

Las líneas que llegan al final de su ciclo de vida necesitan una comprobación adicional. Los paquetes 22, 24 y 26 pasan a las nuevas versiones de origen, por lo que su número de versión cambia como era de esperar. Una adaptación funciona de forma diferente, ya que añade la corrección a la versión existente, de modo que la versión de Node.js de origen sigue siendo la misma y solo cambia el número de versión del paquete. En esas líneas, node --version Parece idéntico antes y después de la actualización, así que compara la versión del paquete instalado con la versión corregida que publican CloudLinux o TuxCare. Los escáneres que solo comparan las cadenas de versión pueden caer en el mismo error y marcar como vulnerable un backport parcheado.

El aviso de Node.js incluirá los detalles de la vulnerabilidad y las versiones originales corregidas una vez que se hagan públicas las actualizaciones. Por otra parte, alt-nodejs Sin embargo, en el servidor, la cuestión práctica es más sencilla. ¿Se ha instalado el paquete actualizado y se ha reiniciado la aplicación en él? En cuanto a las líneas que el desarrollador ha dejado sin resolver, ELS para tiempos de ejecución sigue publicando correcciones, de modo que las migraciones puedan realizarse según el calendario que elija el equipo, en lugar de según el que establezca un organismo consultivo.

Descargar ELS para Runtimes →