Node.js : 10 failles corrigées, quelles mises à jour ?

La faille Node.js octobre 2026 impose de passer au minimum à Node.js 22.23.4, 24.22.1 ou 26.12.1 selon la branche utilisée. Publiées le 21 octobre 2026, ces versions corrigent dix CVE, dont quatre failles de sévérité élevée. La priorité consiste à inventorier chaque environnement, puis à reconstruire et redéployer les applications afin que le moteur réellement exécuté soit corrigé.

Quelles versions corrigent la faille Node.js d’octobre 2026 ?

Les correctifs de sécurité Node.js du 21 octobre 2026 sont intégrés aux versions 22.23.4 LTS, 24.22.1 LTS et 26.12.1 Current. Toute version antérieure appartenant aux branches 22.x, 24.x ou 26.x doit être mise à jour. Une branche arrivée en fin de vie ne reçoit pas ces correctifs officiels.

Node.js est un environnement d’exécution qui permet notamment de faire fonctionner du JavaScript côté serveur. Il peut alimenter une API, le serveur d’un site construit avec Next.js, un traitement automatisé ou un outil interne. La version présente sur le poste d’un développeur ne prouve donc rien sur celle qui tourne en production.

Le piège classique consiste à mettre à jour Node.js sur le serveur hôte alors que l’application utilise son propre moteur dans une image Docker. Même problème avec un artefact de déploiement, un snapshot ou une application mono-exécutable : le binaire vulnérable peut y rester embarqué.

Node.js 22.23.4 actualise aussi c-ares vers 1.34.9, OpenSSL vers 3.5.9, SQLite vers 3.53.4 et Undici vers 6.29.1. Node.js 24.22.1 inclut notamment c-ares 1.34.9, OpenSSL 3.5.9 et Undici 7.30.1, selon les notes de publication du projet Node.js en 2026.

Quel est le risque réel de la faille Brotli CVE-2026-111497 ?

La vulnérabilité CVE-2026-111497 est une écriture hors limites dans le décodeur Brotli intégré à Node.js. Un contenu Brotli malformé peut dépasser un tampon mémoire et provoquer un arrêt, une divulgation de mémoire ou une exécution de code à distance. L’exposition exige toutefois que l’application décompresse des données contrôlées par un attaquant.

Brotli est un algorithme de compression utilisé pour réduire la taille des données. Une écriture hors limites signifie qu’un programme écrit en dehors de la zone de mémoire prévue. L’impact potentiel est sérieux, mais exécuter une version vulnérable ne suffit pas à établir qu’un site est exploitable à distance.

Le 23 octobre 2026, la Cyber Security Agency of Singapore a attribué à CVE-2026-111497 un score CVSS v3.1 de 9,8 et recommandé une correction immédiate. Node.js classe pour sa part la faille au niveau High. Ces deux évaluations emploient des méthodes ou échelles différentes ; elles ne changent pas les versions à installer.

Au 23 octobre 2026, Red Hat indiquait ne pas disposer d’une preuve publique et fiable d’exécution de code à distance. Rapid7 signalait le 26 octobre 2026 ne pas connaître d’exploitation active et précisait que la CVE ne figurait pas alors dans le catalogue Known Exploited Vulnerabilities de la CISA. Cela justifie une mise à jour rapide, pas l’affirmation d’une compromission généralisée.

Que corrigent les neuf autres vulnérabilités Node.js ?

Les mises à jour Node.js d’octobre 2026 corrigent neuf vulnérabilités supplémentaires : trois de sévérité élevée, trois moyennes et trois faibles. Les risques concernent notamment la résolution DNS, la vérification des noms d’hôte TLS, les connexions HTTP persistantes, les adresses IPv4, les valeurs aléatoires et certains contrôles de permissions sur les fichiers.

Les trois autres failles élevées sont CVE-2026-105482, liée à une troncature par octet nul dans le DNS, ainsi que CVE-2026-105483 et CVE-2026-106069, deux contournements de vérification du nom d’hôte TLS. TLS est le protocole qui sécurise les échanges réseau et vérifie notamment l’identité du serveur contacté.

CVE-2026-105483 concerne les branches 24.x et 26.x d’après l’avis Node.js du 21 octobre 2026 ; la branche 22.x n’y est pas indiquée comme affectée. Cette nuance compte lors de l’analyse, mais elle ne doit pas conduire à différer le correctif global d’une branche qui comporte d’autres failles.

Les vulnérabilités moyennes touchent le traitement des réponses HTTP keep-alive avec CVE-2026-105481, les noms d’hôte IPv4 non canoniques avec CVE-2026-106072 et la répétition de valeurs aléatoires dans les snapshots ou applications mono-exécutables avec CVE-2026-106074. Une connexion keep-alive reste ouverte pour transporter plusieurs échanges sans reconnexion systématique.

Les failles faibles sont CVE-2026-106070 dans l’API ZipFile de Node.js 26.x, CVE-2026-106071 dans le modèle de permissions de Node.js 26.x et CVE-2026-106073 dans les contrôles de permissions de fs.realpathSync() pour les branches 22.x, 24.x et 26.x. Comme pour les risques liés aux failles PHP, la gravité théorique doit être rapprochée des fonctions réellement exposées.

Comment vérifier Node.js sur les serveurs, Docker et la CI ?

L’inventaire de la faille Node.js octobre 2026 doit couvrir les moteurs installés sur les hôtes, les processus en service, les conteneurs actifs, les images Docker, les workloads Kubernetes et les pipelines d’intégration continue. La commande node --version est utile, mais son résultat doit être relevé dans le contexte exact où chaque application s’exécute.

Un serveur peut contenir plusieurs exécutables Node.js. Le compte système du service peut aussi utiliser un chemin différent de celui d’une session administrateur. Côté agence, le réflexe est de vérifier le binaire lancé par le gestionnaire de processus plutôt que de s’arrêter à la version affichée dans un terminal.

L’audit opérationnel doit suivre ces points, dans cet ordre :

1. Relever node --version, le chemin de l’exécutable et l’environnement des unités de service sur chaque hôte.
2. Contrôler la version à l’intérieur de chaque conteneur actif avec docker exec <container> node --version.
3. Lire les fichiers Dockerfile et leurs images de base, y compris les tags susceptibles de pointer vers un ancien contenu.
4. Examiner les images déclarées dans les workloads Kubernetes et les registres où elles sont stockées.
5. Vérifier les versions Node.js déclarées dans les workflows CI, les outils de build et les fichiers de configuration.
6. Identifier les snapshots, artefacts et applications mono-exécutables qui embarquent leur propre runtime.

Sur Docker, remplacer seulement un tag dans un fichier sans reconstruire l’image laisse les conteneurs existants inchangés. Ce type d’écart explique aussi pourquoi la correction d’une faille dans Docker exige de contrôler l’image réellement exécutée, et pas uniquement la configuration prévue.

Comment déployer les correctifs sans interrompre l’application ?

Le déploiement des correctifs Node.js doit passer par un environnement de test, puis par la reconstruction des images et artefacts avant un redéploiement progressif. Les processus Node.js doivent être redémarrés. Un remplacement par lots derrière un répartiteur de charge permet de maintenir le service si l’architecture comporte plusieurs instances saines.

Commencez par une sauvegarde exploitable et un test des parcours essentiels : connexion, paiement, envoi d’e-mail, import de fichier, appels d’API et tâches planifiées selon le projet. Vérifiez ensuite les journaux, les erreurs HTTP et l’utilisation des ressources. Une mise à jour du runtime peut révéler une dépendance obsolète, même si le correctif de sécurité lui-même reste compatible avec la branche.

Pour un conteneur, reconstruisez depuis une image de base corrigée, poussez l’image avec un identifiant immuable, puis déployez-la. Kubernetes doit être amené à créer de nouveaux pods ; redémarrer un ancien conteneur fondé sur la même image vulnérable ne corrige rien. Même logique pour la CI : les livrables doivent être régénérés avec le runtime corrigé.

Honnêtement, conserver une branche Node.js en fin de vie pour éviter une campagne de tests reporte le risque au prochain avis de sécurité. À ce stade, mieux vaut planifier une migration vers une branche LTS maintenue, quitte à dissocier le correctif immédiat de la modernisation applicative. Le choix de l’architecture, notamment entre Astro et Next.js pour un projet web, doit aussi intégrer la politique de maintenance du runtime.

Après déploiement, contrôlez à nouveau la version depuis chaque processus ou conteneur actif. Conservez la preuve de la version, de l’image déployée, de la date et du résultat des tests. Une simple modification dans le dépôt Git ne démontre pas que la production a été corrigée.

Cadrer l’inventaire, les tests et le retour arrière avant l’intervention évite la plupart des mauvaises surprises. Un regard extérieur peut surtout aider lorsque plusieurs serveurs, conteneurs et pipelines embarquent des versions différentes du même runtime.

FAQ sur les correctifs Node.js d’octobre 2026

Un site Node.js est-il forcément piratable à distance ?

Un site Node.js vulnérable n’est pas forcément exploitable à distance. CVE-2026-111497 exige que l’application décompresse avec Brotli des données contrôlées par un attaquant, mais la mise à jour reste recommandée sans attendre une preuve d’exploitation.

Mettre à jour Node.js sur le serveur suffit-il avec Docker ?

Mettre à jour Node.js sur l’hôte ne corrige pas le moteur embarqué dans une image Docker. L’image doit être reconstruite depuis une base corrigée, puis les conteneurs doivent être recréés et leur version contrôlée.

Quelle commande affiche la version de Node.js ?

La commande node --version affiche la version de Node.js accessible dans l’environnement courant. Exécutez-la aussi dans les conteneurs et sous le compte utilisé par le service pour éviter de contrôler le mauvais binaire.

Peut-on rester sur une ancienne branche Node.js ?

Une branche Node.js en fin de vie ne reçoit pas les correctifs de sécurité publiés par le projet. Une application en production doit migrer vers une branche LTS prise en charge plutôt que considérer son ancienne version majeure comme corrigée.