Node.js : correctifs de sécurité de niveau élevé le 11 novembre pour les lignes 22, 24 et 26, ce qu'il faut préparer sur un VPS

Sources : pré-alerte « November 2026 Security Releases » du projet Node.js (mise à jour le 3 novembre 2026) ; annonce sur la liste oss-security (4 novembre 2026) ; calendrier des versions Node.js.

Le projet Node.js publie le mercredi 11 novembre 2026, ou peu après, de nouvelles versions de sécurité pour ses trois lignes encore maintenues : Node.js 26, Node.js 24 et Node.js 22. La pré-alerte mise en ligne sur nodejs.org, mise à jour le 3 novembre, puis relayée le 4 novembre sur la liste oss-security par Antoine du Hamel au nom du projet, ne donne qu'une indication de gravité : la vulnérabilité la plus sérieuse corrigée est de sévérité élevée (HIGH), sur chacune des trois lignes. Ni le nombre de failles, ni les numéros CVE, ni les modules touchés ne sont détaillés avant la sortie des correctifs.

Les versions en fin de vie, Node.js 20 et toutes les précédentes, mais aussi Node.js 25, ne recevront rien : le projet rappelle que ces lignes sont toujours concernées quand une release de sécurité sort, sans correctif. Pour un administrateur de VPS Linux ou de serveur dédié, l'annonce laisse une fenêtre utile pour se préparer : savoir où tourne Node.js sur ses machines, par quel canal le runtime a été installé, et ce qu'il faudra redémarrer. Un même serveur cumule souvent plusieurs installations : un binaire NVM pour un bot Discord, le paquet nodejs de NodeSource pour une API, des conteneurs construits sur les images officielles node:*. Cet article prolonge notre guide installer et sécuriser Node.js avec NVM sur un VPS Linux.

Ce que dit la pré-alerte Node.js au 11 novembre

La pré-alerte précède les correctifs de huit jours (mise à jour du 3 novembre pour une sortie le 11) et ne contient aucun détail technique : elle sert à planifier une fenêtre de maintenance. Voici ce qu'elle annonce :

• Lignes corrigées : 26.x, 24.x et 22.x, les trois versions LTS (long term support) encore maintenues ;
• Sévérité maximale : élevée (HIGH), et ce sur les trois lignes ;
• Date : le 11 novembre 2026 « ou peu après », sans heure précise ;
• Versions en fin de vie : toujours affectées lors d'une release de sécurité, sans nouvelle version ;
• Détails : aucun nombre de vulnérabilités, aucune CVE, aucune dépendance citée (OpenSSL, undici, c-ares et les autres ne sont pas mentionnés).

Au moment de la rédaction de cet article, le 11 novembre, l'index officiel des versions (nodejs.org/dist/index.json) ne contient encore aucune version publiée après 26.13.0 (28 octobre), 24.22.2 (27 octobre) et 22.23.4 (octobre). Les versions corrigées seront les premières qui suivront ces numéros sur chaque ligne ; la page de l'avis sera mise à jour avec les liens vers leurs notes de version. Pour être prévenu sans surveiller le site, le projet propose la liste de diffusion nodejs-sec, réservée aux annonces de sécurité et à faible volume.

Quelles versions de Node.js sont concernées

Le tableau ci-dessous croise la pré-alerte avec le calendrier officiel des versions. La colonne « dernière version » indique le numéro que vous verrez avec node -v sur un serveur à jour avant le 11 novembre.

La page « End-of-Life » de nodejs.org est explicite : quand une release de sécurité corrige un défaut dans les lignes maintenues, les lignes en fin de vie ne reçoivent aucune version, même si elles partagent le même code vulnérable. Le même tableau recense déjà, pour Node.js 20, 27 vulnérabilités connues de sévérité élevée, 24 moyennes et 9 faibles, sans correctif. Le projet oriente ceux qui ne peuvent pas migrer vers des offres de support commercial du programme Ecosystem Sustainability de l'OpenJS Foundation, qu'il présente lui-même comme une solution d'attente.

Inventorier les versions de Node.js sur un VPS

Avant le jour J, dressez la liste de tous les endroits où un runtime Node.js s'exécute sur le serveur. Tout se fait en ligne de commande : connectez-vous en SSH au VPS (Virtual Private Server) ou au serveur dédié, puis lancez les commandes ci-dessous dans le terminal, avec un compte qui a les droits sudo. Chaque canal d'installation a sa propre commande d'inventaire et sa propre procédure de mise à jour :

Sur le système et pour chaque utilisateur NVM

Commencez par la version active dans votre shell et par tous les exécutables node présents dans les répertoires du PATH :

node -v
type -a node
apt-cache policy nodejs   # Debian, Ubuntu
rpm -q nodejs             # AlmaLinux, Rocky Linux, Fedora

NVM s'installe par utilisateur : la commande nvm ls lancée en root ne voit pas les versions installées par le compte qui fait tourner votre bot ou votre application. Repérez les installations NVM, puis listez les versions de chaque compte (ici l'utilisateur bot) :

ls -d /root/.nvm /home/*/.nvm 2>/dev/null
sudo -iu bot bash -c '. ~/.nvm/nvm.sh && nvm ls'

Les processus Node.js en cours d'exécution

Le plus fiable reste de partir des processus réellement lancés. Le lien /proc/<PID>/exe indique le binaire utilisé par chaque processus : un chemin NVM contient le numéro de version, et la mention (deleted) signale un processus qui tourne encore avec un binaire remplacé depuis son lancement, donc avec l'ancienne version en mémoire.

ps -eo pid,user,args | grep [n]ode
ls -l /proc/1234/exe

Les conteneurs et les images Docker

Une image construite FROM node:22 puis renommée mon-api:latest n'apparaît pas dans docker image ls node. Interrogez donc chaque conteneur actif, puis cherchez les Dockerfile qui partent d'une image officielle Node.js :

docker ps --format '{{.Names}}\t{{.Image}}'
for c in $(docker ps --format '{{.Names}}'); do echo "$c $(docker exec "$c" node -v 2>/dev/null)"; done
docker image ls node
grep -rni --include='Dockerfile*' '^FROM node' /opt /srv /home 2>/dev/null

Le cas des paquets nodejs des distributions

Les dépôts des distributions livrent leur propre version de Node.js, maintenue par leurs équipes de sécurité et non par le projet Node.js. Au 11 novembre 2026, on trouve 18.20.4 dans Debian 12, 20.19.2 dans Debian 13, 18.19.1 dans Ubuntu 24.04 LTS et 22.22.1 dans Ubuntu 26.04 LTS. Ces paquets reçoivent des correctifs rétroportés au cas par cas, à leur rythme : le suivi de sécurité Debian marquait encore Debian 12 et 13 comme vulnérables à deux failles élevées de la vague d'octobre (CVE-2026-105482 et CVE-2026-106069) le jour de la rédaction. Pour une application exposée sur Internet, ne comptez pas sur eux pour appliquer le correctif de novembre le jour J.

Préparer la mise à jour avec NVM

NVM est un script shell qui fonctionne avec tout shell POSIX (bash, zsh, dash, ksh), sous Unix, sous macOS et sous Windows via WSL ; il s'installe par son script d'installation ou par un simple git clone dans ~/.nvm. Si vous partez de zéro, notre tutoriel Node.js avec NVM sur un VPS Linux détaille l'installation. NVM télécharge les binaires officiels publiés sur nodejs.org : la version corrigée est installable dès sa publication. Pour savoir si elle est sortie, listez les versions distantes de votre ligne :

nvm ls-remote 26

Le jour J, installez la nouvelle version en migrant vos paquets npm globaux (PM2 par exemple), puis faites-en la version par défaut des nouveaux shells. L'option --reinstall-packages-from=26 résout d'abord la version 26 déjà installée localement, puis installe la plus récente et y réinstalle vos paquets globaux. Remplacez 26 par 24 ou 22 selon votre ligne :

nvm install 26 --reinstall-packages-from=26
nvm alias default 26
node -v

Gardez l'ancienne version quelques jours : elle sert de retour arrière immédiat avec nvm use 26.13.0 en cas de bugs de régression, et vous la supprimerez ensuite avec nvm uninstall 26.13.0. Si vos projets contiennent un fichier .nvmrc versionné dans Git, nvm use et nvm install lancés sans argument lisent la version qu'il indique : un .nvmrc qui contient 26 suit automatiquement le correctif, alors qu'un numéro complet comme 26.13.0 devra être modifié dans le dépôt.

PM2 et les unités systemd pointent vers l'ancien chemin

Avec NVM, chaque version vit dans son propre répertoire. Le script de démarrage généré par PM2, qui relance vos applications au boot du serveur, et toute unité systemd écrite à la main contiennent donc le chemin de l'ancienne version. La documentation de PM2 demande, après une mise à jour de Node.js, de régénérer le script de démarrage avec pm2 unstartup puis pm2 startup (exécutez la commande sudo que PM2 affiche), et pm2 update recharge le démon PM2 en mémoire :

pm2 update
pm2 unstartup
pm2 startup
pm2 save

Pour les services que vous avez déclarés vous-même, cherchez les chemins NVM figés dans les unités, corrigez-les, puis rechargez systemd et redémarrez le service (voir notre guide créer un service systemd) :

grep -rn '\.nvm/versions/node' /etc/systemd/system
sudo systemctl daemon-reload
sudo systemctl restart mon-bot.service
journalctl -u mon-bot.service -n 50

La dernière commande affiche le log du service : une erreur de démarrage (exécutable introuvable après le changement de chemin NVM, port déjà occupé) y apparaît tout de suite. Pour les applications gérées par PM2, pm2 logs joue le même rôle.

Préparer la mise à jour avec NodeSource

Le script setup_26.x de NodeSource déclare un dépôt APT au format deb822 dans /etc/apt/sources.list.d/nodesource.sources, qui pointe vers deb.nodesource.com/node_26.x, et ajoute dans /etc/apt/preferences.d/nodejs une priorité de 600 pour que le paquet NodeSource l'emporte sur celui de la distribution. Chaque dépôt suit une seule ligne majeure (node_22.x, node_24.x, node_26.x) : une mise à jour APT ne vous fera jamais changer de version majeure. Vérifiez dès maintenant que la version candidate vient bien de NodeSource :

apt-cache policy nodejs

Le jour J, rafraîchissez les index, contrôlez que la nouvelle version est disponible puis mettez à jour uniquement Node.js :

sudo apt update
apt-cache policy nodejs
sudo apt install --only-upgrade nodejs
node -v

Sur AlmaLinux, Rocky Linux ou Fedora, le dépôt RPM de NodeSource se met à jour avec sudo dnf upgrade --refresh nodejs. Le dépôt conserve les versions précédentes, numérotées sous la forme 26.13.0-1nodesource1, ce qui permet un retour arrière ciblé :

sudo apt install --allow-downgrades nodejs=26.13.0-1nodesource1

Ne comptez pas sur les mises à jour automatiques : dans sa configuration par défaut, unattended-upgrades n'accepte que les origines de la distribution (dépôts de sécurité Ubuntu et ESM, Debian et Debian-Security). Un dépôt tiers comme NodeSource n'est pas mis à jour sans intervention, sauf si vous prenez soin de configurer cette origine vous-même dans la liste des origines autorisées (voir automatiser les mises à jour de sécurité sur un VPS Ubuntu).

Enfin, APT remplace le fichier /usr/bin/node mais pas les processus déjà lancés : ls -l /proc/<PID>/exe affiche alors /usr/bin/node (deleted). Redémarrez chaque service Node.js (systemctl restart, ou pm2 update pour les applications gérées par PM2) et recontrôlez qu'aucun processus ne garde l'ancien binaire.

Pas de reboot, mais une courte coupure derrière le proxy

Contrairement à une mise à jour du noyau Linux, un correctif de Node.js ne demande pas de redémarrer le VPS : relancer les processus Node.js suffit. Si l'application est publiée derrière un reverse proxy Nginx ou Apache, la conf du proxy ne change pas, mais le serveur web renvoie une erreur (502 avec Nginx, 503 avec Apache) tant que le processus Node.js en amont redémarre. Planifiez donc le redémarrage hors des heures de pointe, ou répartissez la charge sur deux instances déclarées dans le bloc upstream de Nginx (deux conteneurs, deux services systemd sur des ports différents) que vous relancez l'une après l'autre. Quel que soit le framework utilisé (Express, Fastify, NestJS, Next.js), c'est le runtime qui est corrigé : vos scripts npm et votre code ne changent pas.

Préparer la mise à jour sur un serveur Plesk

Sur un serveur web administré avec Plesk, qui héberge souvent des sites PHP et des applications Node.js côte à côte, Node.js est fourni par l'extension Node.js Toolkit. Sous Linux, elle permet d'installer plusieurs versions en parallèle et de choisir la version de chaque site ; chaque ligne majeure vit dans son propre répertoire, sous la forme /opt/plesk/node/26/bin/node. La page de l'extension liste les versions installées avec le chemin de leur exécutable, et le même contrôle se fait en ligne de commande :

ls /opt/plesk/node/
/opt/plesk/node/26/bin/node -v
/opt/plesk/node/22/bin/node -v

Depuis 2022, l'équipe Plesk indique que l'extension installe et met à jour automatiquement les versions LTS. Le jour J, vérifiez quand même que chaque répertoire est passé à la version corrigée, puis relancez chaque application : sous Linux, Plesk sert les applications Node.js avec Phusion Passenger, et un processus déjà lancé garde l'ancien runtime. Le bouton Restart App de la page Node.js du domaine (Domains, puis votre domaine, puis Node.js, dans l'interface anglaise) s'en charge. En cas de problème, le log de Passenger se trouve dans /var/log/passenger/passenger.log. Sous Windows, Plesk n'autorise qu'une seule version de Node.js pour tout le serveur, gérée comme un composant de Plesk (Tools & Settings, Updates, Add/Remove Components, composant Node.js Engine).

Reconstruire les images Docker le jour J

Les mainteneurs des images officielles déplacent les tags node:26, node:24-alpine, node:22-bookworm-slim et les autres vers la nouvelle version après sa publication. Vos images locales, elles, ne bougent pas : un conteneur construit hier embarque toujours l'ancien runtime. L'image officielle expose la version de Node.js dans sa variable d'environnement NODE_VERSION, ce qui permet de vérifier que le tag a bien été mis à jour avant de reconstruire :

docker pull node:22-bookworm-slim
docker image inspect --format '{{range .Config.Env}}{{println .}}{{end}}' node:22-bookworm-slim | grep NODE_VERSION

Dans un projet Docker Compose, docker compose build --pull tente toujours de récupérer une version plus récente de l'image de base ; comme chaque couche dépend de la précédente, toutes les étapes qui suivent le FROM sont reconstruites. Pour les services déclarés avec image: node:... sans étape de build, docker compose pull suffit ; l'option --ignore-buildable lui fait ignorer les services qui se construisent localement. docker compose up -d recrée ensuite les conteneurs dont l'image a changé :

cd /opt/mon-app
docker compose build --pull
docker compose pull --ignore-buildable
docker compose up -d
docker compose exec app node -v

Quelques pièges à vérifier dans vos Dockerfile avant le jour J :

• Builds multi-étapes : chaque étape FROM node:... embarque un runtime, celle de compilation comme celle d'exécution ;
• Images épinglées par digest (node:22@sha256:...) : elles ne bougeront jamais seules, mettez le digest à jour à la main ;
• Tags flottants : depuis le passage de Node.js 26 en LTS le 28 octobre, node:lts, node:latest et node:current pointent vers Node.js 26 sur Debian 13 (trixie). Une image construite sur node:lts quand ce tag désignait Node.js 24 changera de version majeure à la reconstruction. Épinglez la ligne majeure, par exemple node:24-bookworm-slim ;
• Base Debian : node:24 et node:22 restent sur Debian 12 (bookworm), alors que node:26 part de Debian 13 (trixie). Les variantes -alpine utilisent Alpine 3.24 et la libc musl (voir musl ou glibc pour vos conteneurs).

Après la reconstruction, les anciennes images restent sur le disque : faites le ménage avec docker image prune une fois la nouvelle version validée, comme expliqué dans notre guide nettoyer Docker avec prune. Si Docker n'est pas encore en place sur votre serveur, partez de installer Docker sur un VPS et Docker Compose sur VPS Linux.

Les postes de développement sous Windows ou macOS

La release de sécurité concerne tous les systèmes pour lesquels nodejs.org publie des binaires, pas seulement les serveurs Linux. Sur un poste de développement sous Windows ou macOS, Node.js vient en général de l'installeur officiel, de NVM (sous macOS, ou sous Windows dans WSL) ou d'un gestionnaire propre à Windows ; le README de NVM cite nvm-windows, nodist et nvs, des projets distincts qu'il ne maintient pas. Mettez ces postes à jour le même jour que la production, pour tester l'application sur la version qui tournera sur le serveur.

Le piège le plus courant vient de Docker Desktop : les images node:* restent en cache sur le poste. Une image construite en local puis poussée vers votre registre, ou construite par une chaîne d'intégration continue qui garde son cache, embarque l'ancien runtime tant que l'image de base n'a pas été tirée de nouveau. Ajoutez --pull à vos commandes docker build ou docker compose build, sur le poste comme sur le serveur.

Récapitulatif : que faire le jour J selon le mode d'installation

Node.js 20 ou 25 : migrer plutôt qu'attendre

Si l'inventaire fait remonter Node.js 20, 25 ou plus ancien, la release de novembre ne vous protégera pas. Visez Node.js 24 (maintenu jusqu'au 30 avril 2028) ou Node.js 26 (jusqu'au 30 avril 2029) plutôt que Node.js 22, dont la fin de vie tombe le 30 avril 2027, dans moins de six mois.

Un changement de version majeure n'est pas un simple apt upgrade. Les modules natifs compilés pour l'ABI d'une version majeure doivent être recompilés pour la nouvelle (ceux qui reposent sur Node-API restent compatibles) : dans le doute, lancez npm rebuild, ou supprimez node_modules et relancez npm ci. Les drivers de base de données les plus répandus n'ont, eux, rien à recompiler : mysql2 pour MySQL, le connecteur mariadb pour MariaDB et pg pour PostgreSQL sont écrits en JavaScript, sans module natif ; seule la liaison optionnelle pg-native, construite sur libpq, l'est. Vérifiez aussi le champ engines du package.json, mettez à jour le fichier .nvmrc et testez l'application sur une copie avant de basculer la production. Une sauvegarde du VPS (backup des fichiers de l'application et dump de la base) faite juste avant la migration permet de revenir en arrière en cas de surprise.

Le précédent d'octobre : Node2Shell

Cette release arrive trois semaines après la précédente. Le 21 octobre 2026, Node.js 26.12.1, 24.22.1 et 22.23.4 corrigeaient dix vulnérabilités, dont quatre de sévérité élevée selon le classement du projet. Parmi elles, CVE-2026-111497, une écriture hors limites dans le décodeur Brotli de node:zlib, surnommée Node2Shell, que nous avions détaillée dans Node2Shell : faille RCE dans Node.js et Python puis dans HTTP2Shell : la faille Brotli au-delà de Node.js. Les autres touchaient la résolution DNS, la vérification d'identité TLS sur des adresses IP et le modèle de permissions, avec des mises à jour de c-ares, undici, des certificats racine et, sur 24.x et 22.x, d'OpenSSL.

Deux vagues en trois semaines : la mise à jour de Node.js doit devenir une procédure répétable, pas une opération improvisée. Un script d'inventaire, une procédure écrite par canal d'installation et un pipeline de reconstruction des images suffisent à passer le jour J en quelques minutes. Les outils construits sur Node.js en profitent aussi, comme Node-RED, dont l'API d'administration était exploitée en octobre (CVE-2026-58115 : Node-RED exploitée).

Lexique de la mise à jour Node.js

• Release de sécurité : nouvelles versions des lignes maintenues qui corrigent les failles signalées au projet, annoncées à l'avance par une pré-alerte sans détails techniques.
• LTS (long term support) : ligne maintenue environ trois ans après sa sortie, d'abord en LTS active puis en LTS de maintenance, qui ne reçoit plus que les correctifs importants.
• Fin de vie (EOL) : date après laquelle une ligne ne reçoit plus aucune version, même lors d'une release de sécurité qui corrige un défaut qu'elle partage.
• CVE : identifiant public d'une vulnérabilité, publié par le projet Node.js avec les versions corrigées, jamais dans la pré-alerte.
• NVM : gestionnaire de versions installé par utilisateur, qui place chaque version de Node.js dans son propre répertoire.
• NodeSource : dépôt APT et RPM qui livre une ligne majeure de Node.js sous forme de paquet nodejs.
• Module natif : dépendance npm écrite en C ou C++. Compilé pour l'ABI d'une version majeure, il se recompile avec npm rebuild après un changement de version majeure ; construit sur Node-API, il reste compatible d'une majeure à l'autre. Un correctif dans la même ligne ne demande aucune recompilation.
• Reverse proxy : serveur web (Nginx, Apache) qui reçoit le trafic HTTPS et le transmet à l'application Node.js qui écoute sur un port local.

En résumé

Le 11 novembre 2026 ou dans les jours suivants, Node.js publie des correctifs de sécurité de sévérité élevée pour les lignes 26, 24 et 22 ; les versions en fin de vie, dont Node.js 20, restent vulnérables. Inventoriez dès maintenant chaque runtime de vos serveurs (node -v, nvm ls par utilisateur, apt-cache policy nodejs, docker exec ... node -v), préparez la commande de mise à jour propre à chaque canal, puis, le jour J, redémarrez les processus et reconstruisez les images Docker. Vous hébergez un bot sur Node.js ? Notre offre d'hébergement de bot Discord le fait tourner avec un panel et l'anti-DDoS inclus ; pour garder la main sur le runtime, un VPS Linux ou un serveur dédié vous laisse l'accès root.