11 novembre : mises à jour de sécurité Node.js pour les versions prises en charge et celles en fin de vie

Principaux enseignements

• Node.js prévoit de publier des correctifs de gravité élevée pour les versions 22.x, 24.x et 26.x le 11 novembre ou peu après.
• Upstream considère les versions en fin de vie comme concernées, mais ne propose aucun correctif pour celles-ci.
• ELS for Runtimes prépare actuellement des correctifs rétroportés pour huit versions de Node.js arrivées en fin de vie, sur l'ensemble des distributions prises en charge.
• Redémarrez chaque application Node.js après la mise à jour, et vérifiez les rétroportages de fin de vie par version du paquet, et non node --version.

Node.js a prévu sa prochaine série de mises à jour de sécurité pour le mercredi 11 novembre 2026, ou peu après. De nouvelles versions sont attendues pour les branches 22.x, 24.x et 26.x, et le projet attribue le niveau de gravité « Élevé » à la faille la plus grave de chaque branche. Les identifiants CVE et les détails techniques resteront confidentiels jusqu’à la publication des mises à jour ; il convient donc de considérer avec une grande méfiance toute affirmation prématurée concernant des méthodes d’attaque spécifiques.

Pour les équipes qui utilisent Node.js via alt-nodejs En ce qui concerne les paquets, cette annonce ne représente que la moitié de l’histoire. Cela inclut les serveurs d’hébergement CloudLinux ainsi que les hôtes Debian, Ubuntu, Alpine et Enterprise Linux couverts par le programme « Endless Lifecycle Support » (ELS) de TuxCare pour Node.js. Un correctif publié sur nodejs.org ne corrige pas, à lui seul, les éléments en cours d’exécution sur ces systèmes. Les paquets mis à jour doivent être compilés, publiés et installés, et les applications en cours d’exécution doivent être redémarrées avant que le correctif ne prenne effet. La plupart des préparatifs peuvent être effectués dès maintenant, bien avant que les détails ne soient dévoilés.

Les lignes de fin de vie en amont ne peuvent pas être réparées

La version en amont ne concerne que les versions 22, 24 et 26. L'avis de sécurité de Node.js précise que les versions en fin de vie sont toujours concernées par une mise à jour de sécurité, même si le développeur en amont ne propose plus de correctifs pour celles-ci. Cela ne signifie pas que chaque ancienne version comporte tous les bogues récemment corrigés, mais aucune installation fonctionnant sous Node.js 20, 18 ou une version antérieure ne doit être considérée comme sûre simplement parce que sa version ne figure pas sur la liste des versions concernées.

C'est précisément cette lacune que comble le service ELS for Runtimes. L'équipe ELS de TuxCare prépare actuellement des correctifs rétroportés pour huit produits en fin de vie alt-nodejs lignes, Node.js 10, 12, 14, 16, 18, 19, 20 et 23 ; ainsi, une application épinglée à un runtime plus ancien pourra bénéficier des correctifs de cette série sous forme de mise à jour du paquet, plutôt que de devoir procéder à une migration d’urgence. Le backporting est un véritable travail d’ingénierie – le correctif doit être adapté à du code qui n’est plus maintenu en amont –, mais il est prévu de publier ces versions le 11 novembre en même temps que le reste, peu après la sortie de la version en amont. Le Documentation sur ELS pour les environnements d'exécution répertorie les versions de Node.js prises en charge sur chaque système d'exploitation.

Quels dépôts contiennent les versions corrigées ?

Sur CloudLinux, Node.js Selector fonctionne sur alt-nodejs les paquets, et la version de Node.js est choisie par application, et non par serveur ni même par compte. C'est ainsi qu'un serveur d'hébergement finit discrètement par exécuter trois ou quatre versions de Node.js en parallèle, y compris certaines qui ne sont plus prises en charge en amont.

La même chose alt-nodejs Les paquets sont également mis à disposition via les dépôts de TuxCare pour les clients ELS, couvrant Debian 10 à 13, Ubuntu 18.04 à 26.04, ainsi qu’Alpine 3.23 et 3.24, sans oublier les versions signées par TuxCare pour Enterprise Linux. Ils s’installent sous /opt/alt/, en plus de la version de Node.js déjà fournie par la distribution, et de la mettre à jour via la procédure habituelle yum, aptou apk flux de travail. Les versions de Node.js 23 ne sont disponibles que sur Debian 12, Debian 13 et Alpine.

Quand les paquets mis à jour seront-ils disponibles ?

CloudLinux prévoit de commencer la compilation dès que Node.js aura publié les correctifs et prévoit de publier une version mise à jour alt-nodejs les paquets plus tard dans la journée. Cela concerne les versions 22, 24 et 26, ainsi que les versions en fin de vie de toutes les versions de CloudLinux, de la 6 à la 10, et les versions du dépôt TuxCare sont publiées au cours de la même session. Ce calendrier dépend de la sortie en amont ; il s'agit donc d'un objectif et non d'une date de livraison fixe.

Les hébergements CloudLinux proposent deux autres types de paquets Node.js, chacun avec son propre processus de mise à jour. Sur les serveurs cPanel exécutant CloudLinux 8, ea-nodejs22 provient également des dépôts CloudLinux, mais il est compilé à partir du paquet de cPanel. Sa correction dépend de la publication préalable d’une version mise à jour par cPanel, puis de la mise à disposition du paquet correspondant par CloudLinux. Le système d’exploitation natif nodejs Les paquets suivent à nouveau un parcours distinct, via les mises à jour régulières des systèmes d’exploitation RHEL et AlmaLinux. Tout environnement d’exécution installé en dehors de ces canaux doit faire l’objet d’une vérification spécifique, car un alt-nodejs La mise à jour ne le modifiera pas.

Préparatifs à effectuer avant mercredi

Sur CloudLinux, abonnez-vous à la page d'état de CloudLinux dédiée à cette version. CloudLinux prévoit de communiquer une estimation de l'heure de disponibilité (ETA) tôt dans la matinée du mardi 10 novembre, puis de publier des mises à jour sur l'avancement toutes les quelques heures jusqu'à ce que les paquets soient disponibles. Les clients ELS utilisant d'autres distributions peuvent consulter la liste des correctifs Node.js disponibles chez TuxCare pour connaître les versions corrigées.

Ensuite, faites l'inventaire. Exécutez la commande qui correspond au gestionnaire de paquets de l'hôte (RPM, DEB ou APK) :

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

Cela indique quelles versions sont installées, mais pas quelles applications les utilisent. Sous CloudLinux, vérifiez également « Node.js Selector » pour voir la version attribuée à chaque application. Par ailleurs, les unités systemd, les configurations PM2 et les images de conteneurs peuvent chacune pointer vers un binaire différent ; vérifiez-les donc également. Une seule application oubliée lors de la fenêtre de mise à jour peut continuer à fonctionner avec un ancien runtime alors que tout le reste semble à jour.

Prévoyez ensuite des redémarrages, car la mise à jour du paquet ne suffit pas à elle seule. L'installation d'un paquet mis à jour remplace le fichier binaire sur le disque, mais une application Node.js en cours d'exécution continue d'utiliser l'ancienne version jusqu'à son redémarrage, quoi qu'en dise le gestionnaire de paquets.

Les applications gérées via Node.js Selector peuvent être redémarrées depuis son interface ou à l'aide de cette commande, en indiquant le nom du compte et le répertoire racine de l'application :

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

Tout ce qui s'exécute en dehors de Node.js Selector est redémarré selon la procédure habituelle de gestion de ce service. Ensuite, cette liste répertorie tous les processus Node.js en cours d'exécution avec leur heure de démarrage, ce qui permet de repérer facilement tout ce qui a été lancé avant la mise à jour :

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

Sur les serveurs hébergeant de nombreuses applications, définissez à l'avance l'ordre de redémarrage et coordonnez-vous avec les responsables des applications lorsque les temps d'indisponibilité sont critiques. Un redémarrage planifié et échelonné est préférable à un redémarrage précipité le soir de la mise en production.

Que faire une fois que les colis sont arrivés ?

Lorsque le alt-nodejs Les paquets sont disponibles ; installez-les via votre processus habituel de gestion des paquets, puis redémarrez les applications concernées. Vérifiez ensuite que chaque application a redémarré correctement et qu’elle utilise bien la version mise à jour du runtime. Le fait que l’installation des paquets se soit déroulée sans problème ne garantit pas que toutes les applications aient bien intégré le correctif.

Les lignes en fin de vie nécessitent une vérification supplémentaire. Les paquets 22, 24 et 26 passent aux nouvelles versions en amont, leur numéro de version change donc comme prévu. Un backport fonctionne différemment : il ajoute le correctif à la version existante, de sorte que la version en amont de Node.js reste la même et que seul le numéro de version du paquet change. Sur ces lignes, node --version L'apparence reste identique avant et après la mise à jour ; il convient donc de comparer la version du paquet installé avec la version corrigée publiée par CloudLinux ou TuxCare. Les outils de scan qui se contentent de comparer les chaînes de version peuvent se tromper et signaler un backport corrigé comme vulnérable.

L'avis de sécurité Node.js contiendra les détails de la vulnérabilité ainsi que les versions en amont corrigées dès que celles-ci seront rendues publiques. Sur un alt-nodejs Sur le serveur, cependant, la question pratique est plus simple. Le paquet mis à jour a-t-il été installé, et l'application a-t-elle été redémarrée sur celui-ci ? Quant aux lignes que l'amont a laissées derrière lui, ELS pour les durées d'exécution permet de continuer à proposer des correctifs, de sorte que les migrations puissent s'effectuer selon un calendrier choisi par l'équipe elle-même, plutôt que selon celui imposé par un organisme de recommandation.

Télécharger ELS pour Runtimes →

Références

Node.js, « Mises à jour de sécurité du mercredi 11 novembre 2026 »

Page d'état de CloudLinux, « Mises à jour de sécurité Node.js, 11 novembre 2026 »

TuxCare Documentation