Failles Node.js d’octobre 2026 : versions et mise à jour

Les failles Node.js d’octobre 2026 sont corrigées dans les versions 22.23.4, 24.22.1 et 26.12.1, publiées le 21 octobre. Le lot couvre dix CVE, dont quatre de gravité haute, avec des différences selon la branche. La priorité consiste à identifier le moteur réellement exécuté, appliquer la version adaptée et contrôler les services après leur remise en route.

Vérification documentaire : 21 octobre 2026. Les gravités et branches ci-dessous suivent l’annonce de sécurité Node.js, recoupée avec les notes de version officielles.

Quelles failles Node.js sont corrigées en octobre 2026 ?

Les correctifs concernent le DNS, TLS, Brotli, HTTP, la cryptographie et les permissions. La gravité maximale publiée est haute. L’exécution de code à distance figure parmi les impacts possibles de la faille Brotli, sans permettre de conclure que toute application Node.js est exploitable de la même façon.

La répartition est donc quatre hautes, trois moyennes et trois faibles. CVE-2026-106072 reste moyenne dans cette matrice : certaines notes regroupent son correctif avec celui de CVE-2026-106069 sous une ligne marquée haute. La classification individuelle de l’annonce évite cette confusion.

La version doit être relevée dans le service actif ; reconstruire une image ne suffit pas sans redéployer.

Quelles versions installer dans les branches 22, 24 et 26 ?

Chaque branche possède sa propre version corrigée pour cette livraison. Les notes officielles donnent les cibles suivantes :

• Node.js 22.23.4, dans la branche 22 LTS.
• Node.js 24.22.1, dans la branche 24 LTS.
• Node.js 26.12.1, dans la branche 26 Current.

La branche 22 est concernée par sept des dix CVE, la branche 24 par huit et la branche 26 par dix. CVE-2026-105483 ne figure pas pour la branche 22 ; les problèmes ZipFile et jokers sont annoncés uniquement pour la branche 26. Cela ne dispense aucune de ces branches de sa mise à jour.

Les notes signalent aussi des mises à jour de dépendances intégrées. Une mise à jour des seuls paquets applicatifs ne prouve donc pas que le binaire Node.js a reçu les corrections.

Comment vérifier le Node.js réellement utilisé ?

La commande node -v affiche la version du binaire invoqué dans le contexte où elle est exécutée. Cette option est décrite dans la documentation de la ligne de commande. Un résultat obtenu sur un poste de développement ne décrit pas les services en production.

Demandez à l’équipe d’exploitation de relever, pour chaque application :

• la version exécutée et le chemin du binaire utilisé par le service ;
• le serveur, le conteneur ou l’environnement managé concerné ;
• les traitements associés, notamment tâches planifiées et processus en arrière-plan ;
• le responsable de la mise à jour et les fonctions à tester.

Pour une fonction serverless ou un service administré par un fournisseur, vérifiez la révision du moteur auprès de celui-ci. Pour un paquet corrigé par rétroportage, conservez un avis fournisseur couvrant les CVE pertinentes. La gouvernance des systèmes IA inclut aussi cette attribution des responsabilités lorsque Node.js porte des connecteurs ou des agents.

Comment corriger les conteneurs Docker ?

Un conteneur doit repartir d’une image contenant le moteur corrigé. Docker rappelle dans ses bonnes pratiques de construction que les images sont immuables et recommande de les reconstruire avec des dépendances actualisées.

Identifiez l’image de base, sa version et son empreinte. Préparez une reconstruction à partir de la base corrigée, testez l’image obtenue, puis redéployez les instances concernées. Relisez ensuite la version à l’intérieur des nouveaux conteneurs. Modifier le fichier de construction sans remplacer les instances actives ne clôt pas l’intervention.

Vérifiez également les étapes de construction qui utilisent Node.js, même si l’image finale n’en contient pas. Conservez une procédure de reprise et les sauvegardes nécessaires avant la bascule. Notre accompagnement à l’intégration des innovations permet de cadrer ces dépendances dans les applications reliées aux usages IA.

Que faire avec Node.js 18 ou 20 ?

Node.js 18 et 20 sont en fin de support officiel au 21 octobre 2026. Le calendrier du projet Node.js fixe leur fin de vie au 30 avril 2025 et au 30 avril 2026 respectivement. Aucune version corrigée de ces branches n’est annoncée dans cette livraison.

Préparez une migration vers une branche maintenue avec les responsables applicatifs. Un maintien commercial éventuel doit être justifié par le fournisseur et par la couverture des correctifs ; il ne rétablit pas le support du projet Node.js. Ne recopiez pas automatiquement la matrice des branches 22, 24 et 26 sur les anciennes branches : les sources consultées ne détaillent pas leur exposition CVE par CVE.

Quels tests réaliser après la mise à jour ?

La vérification doit couvrir la version active et les échanges réellement utilisés. Voici une méthode de contrôle proposée pour les services concernés :

1. HTTPS sortant. Rejouer les appels aux API habituelles et vérifier les certificats, noms d’hôte et erreurs nouvelles. Conserver les contrôles TLS ; leur désactivation ne constitue pas une correction.
2. DNS. Vérifier les résolutions nécessaires au fonctionnement et la gestion des échecs, avec des cas ordinaires maîtrisés.
3. Contenus compressés. Tester les traitements légitimes qui décompressent des données, dont Brotli lorsqu’il est utilisé, ainsi que la gestion des erreurs.
4. Fonctions particulières. Contrôler les connexions HTTP persistantes, les restrictions fichiers et les applications construites avec des images de démarrage ou des exécutables autonomes lorsqu’elles sont présentes.

CVE-2026-106074 vise précisément les caches de crypto.randomUUID() et randomInt() conservés dans des snapshots ou des SEA. Revoyez ces artefacts avec l’équipe qui les produit. Archivez versions, révisions d’images et résultats selon la logique d’un registre de preuves en production.

Que sait-on de l’exploitation de ces failles ?

Au 21 octobre 2026, les sources Node.js consultées ne précisent ni une exploitation observée ni la disponibilité d’un exploit public. Ce silence ne permet pas d’affirmer leur absence. Il faut distinguer impact possible, attaque constatée et état de ses propres systèmes.

L’annonce décrit une écriture hors limites dans le décodeur Brotli pouvant permettre une exécution de code à distance. Elle ne confirme pas le scénario particulier associant fetch() à une réponse compressée. Cet article ne l’utilise donc pas pour qualifier l’exposition.

Si des indices de compromission existent, prévoyez une investigation distincte. Le correctif ne tranche pas l’historique des accès, notamment pour les applications qui doivent aussi sécuriser les agents et leurs données.

Comment Noolya intervient ?

Noolya intervient pour vérifier l’exposition, préparer la mise à jour et contrôler son application avec les responsables techniques. Le périmètre peut comprendre l’inventaire des moteurs, l’examen des correctifs fournisseur, la reconstruction des images, la mise à jour autorisée, les tests de non-régression et la vérification des processus actifs.

Le diagnostic faille Node.js aide à préparer les informations disponibles. Cette auto-évaluation déclarative ne scanne aucun serveur et ne certifie pas la correction d’une installation.

Noolya intervient : vérification et mise à jour. Contactez Noolya pour définir le diagnostic détaillé, les accès autorisés et les contrôles adaptés à votre environnement.

Questions fréquentes

Faut-il passer à Node.js 26 pour obtenir les correctifs ? Les branches 22 et 24 disposent aussi d’une version corrigée, respectivement 22.23.4 et 24.22.1. Le changement de branche dépend de la compatibilité applicative et du calendrier de support ; il ne remplace pas les tests.

Une mise à jour npm suffit-elle pour ce lot ? Le lot corrige le moteur Node.js et des dépendances intégrées à sa distribution. Vérifiez le binaire exécuté après intervention : la mise à jour des dépendances du projet ne prouve pas celle du moteur.

Une application sans accès web public doit-elle être vérifiée ? La matrice concerne aussi des composants utilisés dans les échanges sortants et des fonctions locales. L’inventaire doit donc couvrir les traitements internes utilisant ces composants, avec une appréciation des fonctions effectivement sollicitées.

Un diagnostic déclaratif peut-il prouver que Node.js est corrigé ? Un questionnaire ne vérifie ni les binaires ni les images réellement actifs. La preuve exige les versions exécutées, l’avis fournisseur si nécessaire et les résultats des contrôles après mise à jour.

Sources

• Wednesday, October 21, 2026 Security Releases : Node.js, 21 octobre 2026 ; dix CVE, gravités et branches.
• Node.js 22.23.4 (LTS) : version de sécurité du 21 octobre 2026.
• Node.js 24.22.1 (LTS) : version de sécurité du 21 octobre 2026.
• Node.js 26.12.1 (Current) : version de sécurité du 21 octobre 2026.
• Node.js Release Working Group : calendrier de support consulté le 21 octobre 2026.
• Command-line API : documentation Node.js ; lecture de la version du binaire.
• Building best practices : Docker ; reconstruction des images avec des dépendances actualisées.
• Node.js atklātas vairākas augstas bīstamības ievainojamības : CERT.LV, 21 octobre 2026 ; confirmation des dix CVE et des versions corrigées.