Faille Node.js d'octobre 2026 : versions touchées et mise à jour

Par Mouhamed BANKOLE, CEO chez ITNET Technologies · Mis à jour le 27 octobre 2026 · Lecture : 8 min

Le 21 octobre 2026, le projet Node.js a publié des mises à jour de sécurité qui corrigent dix failles, dont quatre de gravité élevée, sur les branches 22, 24 et 26 (annonce de nodejs.org). La plus grave, CVE-2026-111497, est notée 9,8 sur 10 par l'agence de cybersécurité de Singapour et peut conduire à une exécution de code à distance (alerte CSA). Si vous faites tourner une API, un site Next.js, un bot ou un outil comme n8n sur un serveur, cette faille Node.js vous concerne probablement. Voici ce qui est établi, les versions touchées, comment vérifier la vôtre et quoi faire aujourd'hui.

En résumé

• Node.js a corrigé dix failles le 21 octobre 2026, dont quatre de gravité élevée, sur les branches 22, 24 et 26.
• Les versions sûres sont Node.js 26.12.1, 24.22.1 et 22.23.4 ou plus récentes ; les versions en fin de vie sont aussi touchées et ne sont plus corrigées.
• La faille la plus grave (CVE-2026-111497) touche la décompression Brotli et peut mener à une exécution de code à distance ; une preuve de concept publique existe.
• Sur un VPS ou un serveur dédié, la mise à jour est à votre charge, y compris dans vos images Docker.
• Vérifiez votre version avec node -v, mettez à jour, redémarrez vos processus et reconstruisez vos conteneurs.

Sommaire

1. Que s'est-il passé avec Node.js le 21 octobre 2026 ?
2. Quelles versions de Node.js sont touchées ?
3. Quelle est la faille la plus grave ?
4. Qu'est-ce que cela change pour vos applications ?
5. Comment connaître votre version de Node.js ?
6. Que faire concrètement dès aujourd'hui ?
7. Comment mettre à jour Node.js sur un VPS ou dans Docker ?
8. Qui doit faire la mise à jour selon votre hébergement ?
9. Que faire si votre version de Node.js n'est plus maintenue ?

Que s'est-il passé avec Node.js le 21 octobre 2026 ?

Le projet Node.js a publié le 21 octobre 2026 des versions correctives pour ses trois branches maintenues, qui règlent dix vulnérabilités (nodejs.org). Ces correctifs sont sortis le même jour que ceux de PHP, une journée que le média Next a qualifiée de « journée noire » pour la cybersécurité (Next).

Ce qui est établi, d'après les sources officielles :

• dix CVE sont corrigées : quatre de gravité élevée, trois moyennes et trois faibles (nodejs.org) ;
• les branches 22, 24 et 26 sont concernées, pas toutes au même degré (nodejs.org) ;
• le CERT de Hong Kong classe ces failles en risque élevé et signale une preuve de concept publique pour CVE-2026-111497 (HKCERT) ;
• l'agence de Singapour recommande de mettre à jour immédiatement (CSA).

Ce qui n'est pas établi à ce jour : aucune des sources consultées ne signale d'exploitation active de ces failles (nodejs.org, CSA).

Quelles versions de Node.js sont touchées ?

Toutes les versions de Node.js antérieures aux correctifs du 21 octobre 2026 sont touchées, y compris les versions en fin de vie, que le projet ne corrige plus (nodejs.org).

Sources : annonce de nodejs.org et bulletin du HKCERT.

Les quatre failles de gravité élevée, selon l'éditeur (nodejs.org) :

Quelle est la faille la plus grave ?

La plus grave est CVE-2026-111497, une écriture hors limites dans le décodeur Brotli de Node.js, notée 9,8 sur 10 en CVSS v3.1 par l'agence de Singapour (CSA).

Ce que l'on sait de cette faille :

• elle se déclenche quand une application décompresse avec node:zlib des données Brotli fournies par un tiers (nodejs.org) ;
• les conséquences possibles sont un plantage, une fuite de mémoire du processus ou une exécution de code à distance (nodejs.org) ;
• une preuve de concept publique existe, ce qui en fait la correction la plus urgente selon le HKCERT (HKCERT).

Analyse : les applications les plus exposées sont celles qui acceptent du contenu compressé venant de l'extérieur (API, proxys, outils d'automatisation qui récupèrent des pages web). Faute de pouvoir auditer chaque dépendance, la mise à jour reste la seule réponse fiable.

Qu'est-ce que cela change pour vos applications ?

Si votre serveur exécute une version de Node.js non corrigée, un attaquant pourrait faire planter vos applications, lire une partie de leur mémoire ou, dans le pire cas, exécuter du code sur le serveur.

Les risques concrets :

• interruption de service : API, site ou bot qui tombe en boucle ;
• fuite de secrets : clés d'API, jetons, variables d'environnement présentes en mémoire ;
• prise de contrôle du serveur et rebond vers vos bases de données ;
• contournement de contrôles TLS pour les failles liées aux certificats, qui touchent les connexions sortantes de vos applications.

Les usages typiques concernés : sites Next.js ou Nuxt en rendu serveur, API Express ou Fastify, outils d'automatisation auto-hébergés comme n8n, bots et workers. Pour mesurer l'enjeu sur une application d'IA auto-hébergée, voyez notre guide pour héberger une application IA.

Comment connaître votre version de Node.js ?

Tapez node -v dans un terminal sur le serveur : la commande affiche la version exacte, à comparer au tableau des versions corrigées.

Selon votre installation :

1. en direct sur le serveur : node -v ;
2. dans un conteneur Docker : docker exec <conteneur> node -v, pour chaque conteneur ;
3. avec un gestionnaire de versions (nvm, fnm) : nvm ls liste toutes les versions installées ;
4. dans votre CI : vérifiez l'image ou l'action qui installe Node.js, souvent figée sur une ancienne version.

Conseil de pro : un serveur peut avoir plusieurs versions de Node.js. Vérifiez aussi celle utilisée par le gestionnaire de processus (PM2, systemd), pas seulement celle de votre session.

Que faire concrètement dès aujourd'hui ?

Installez la version corrigée de votre branche, redémarrez tous les processus Node.js, puis reconstruisez et redéployez vos conteneurs.

La liste d'actions, dans l'ordre :

1. inventoriez vos serveurs, conteneurs et pipelines qui utilisent Node.js ;
2. lisez les notes de version de l'éditeur avant d'installer (nodejs.org) ;
3. testez sur un environnement de préproduction si votre application est critique ;
4. prenez un instantané du serveur avant la mise à jour ;
5. mettez à jour vers 22.23.4, 24.22.1 ou 26.12.1 ;
6. redémarrez les processus (PM2, systemd) : un Node.js mis à jour mais non redémarré reste vulnérable ;
7. contrôlez avec node -v et surveillez les journaux.

Comment mettre à jour Node.js sur un VPS ou dans Docker ?

La méthode dépend de la façon dont Node.js a été installé : gestionnaire de paquets, gestionnaire de versions ou image Docker.

Les cas les plus courants :

• paquets système (dépôt de distribution ou dépôt Node.js) : mettez à jour le paquet nodejs avec le gestionnaire de votre système, puis redémarrez les services ;
• nvm ou fnm : installez la nouvelle version de votre branche, définissez-la par défaut et relancez vos processus avec elle ;
• Docker : mettez à jour la balise de l'image de base (par exemple node:22 vers la dernière 22.x), reconstruisez l'image sans cache et redéployez ;
• intégration continue : mettez à jour la version déclarée dans vos fichiers de configuration pour que les prochains builds utilisent la version corrigée.

Sur un VPS Wayhost, l'accès root complet permet d'appliquer ces mises à jour vous-même, et les snapshots instantanés se créent depuis l'espace client avant l'opération (constaté le 27 octobre 2026).

Qui doit faire la mise à jour selon votre hébergement ?

Sur un serveur que vous administrez, VPS ou serveur dédié, c'est à vous de mettre à jour Node.js ; sur une plateforme gérée, c'est en principe le fournisseur, mais vérifiez la version utilisée.

Pour des applications gourmandes ou nombreuses, un serveur physique Wayhost offre des CPU dédiés, du stockage NVMe et une protection DDoS incluse (constaté le 27 octobre 2026). Pour un site vitrine ou WordPress sans Node.js côté serveur, l'hébergement web mutualisé laisse les mises à jour système à l'hébergeur. Si vous hésitez entre ces formules, notre guide VPS : c'est quoi ? compare les options.

Que faire si votre version de Node.js n'est plus maintenue ?

Migrez vers une branche maintenue, car le projet Node.js indique que les versions en fin de vie sont aussi touchées et ne recevront pas de correctif (nodejs.org).

Pour préparer la migration :

• listez vos dépendances et vérifiez leur compatibilité avec Node.js 22 ou 24 ;
• lancez vos tests sur la nouvelle version dans un environnement séparé ;
• privilégiez une branche LTS (22 ou 24) pour la production ;
• planifiez les prochaines montées de version pour ne plus rester sur une branche abandonnée.

C'est la même logique que pour PHP, dont les failles critiques ont été corrigées le même jour : voyez notre article sur la faille PHP et la mise à jour à faire.

Questions fréquentes

Quelle est la faille Node.js d'octobre 2026 ?

Il s'agit d'un lot de dix vulnérabilités corrigées par le projet Node.js le 21 octobre 2026, dont quatre de gravité élevée. La plus grave, CVE-2026-111497, touche la décompression Brotli et peut mener à une exécution de code à distance. Une preuve de concept publique existe.

Quelles versions de Node.js faut-il installer ?

Les versions 26.12.1, 24.22.1 et 22.23.4, ou plus récentes, corrigent ces failles. Choisissez celle de votre branche actuelle pour limiter les risques d'incompatibilité. Les branches en fin de vie ne reçoivent pas de correctif.

Comment savoir si mon serveur utilise une version vulnérable ?

Lancez node -v sur le serveur et dans chaque conteneur. Comparez le résultat aux versions corrigées de votre branche. Une version inférieure est vulnérable.

La faille est-elle exploitée activement ?

Les sources officielles consultées ne signalent pas d'exploitation active à ce jour. En revanche, une preuve de concept publique existe pour la faille la plus grave. Le risque d'attaques augmente donc tant que les serveurs ne sont pas à jour.

Faut-il redémarrer après la mise à jour de Node.js ?

Oui. Les processus déjà lancés continuent d'utiliser l'ancienne version en mémoire. Redémarrez vos services et vérifiez la version utilisée par PM2 ou systemd.

Mes conteneurs Docker sont-ils protégés si le serveur est à jour ?

Non. Chaque conteneur embarque sa propre version de Node.js, indépendante de celle du serveur. Il faut mettre à jour l'image de base, reconstruire l'image et redéployer le conteneur.

Mon site WordPress est-il concerné ?

En général non, car WordPress fonctionne avec PHP et non avec Node.js. Il peut l'être si vous utilisez des outils Node.js côté serveur. Pensez en revanche à vérifier la version de PHP, corrigée le même jour.

Ce qu'il faut retenir

• Dix failles de Node.js ont été corrigées le 21 octobre 2026, dont quatre de gravité élevée.
• Les versions 26.12.1, 24.22.1 et 22.23.4 ou plus récentes les corrigent.
• CVE-2026-111497 est la plus urgente : exécution de code possible et preuve de concept publique.
• Sur un VPS ou un serveur dédié, c'est à vous de mettre à jour, redémarrer et reconstruire vos conteneurs.
• Les versions en fin de vie ne sont plus corrigées : il faut migrer.

Pour faire tourner vos applications Node.js avec un accès root complet et des snapshots avant chaque mise à jour, découvrez les VPS Wayhost.

Article rédigé par Mouhamed BANKOLE, CEO chez ITNET Technologies.