Le projet Node.js a annoncé des correctifs de sécurité pour les lignes 26.x, 24.x et 22.x, attendus le mercredi 21 octobre ou peu après, avec au moins une faille de sévérité haute. Le même mois s’ouvre la phase alpha de Node.js 27, la première version du nouveau rythme à une seule version majeure par an.
Plan de l'article
- Que contient l’annonce de sécurité du 21 octobre ?
- Comment se préparer d’ici mercredi ?
- Pourquoi octobre 2026 est un mois charnière pour Node.js ?
- Qu’est-ce qui change avec une seule version majeure par an ?
- À quoi sert la phase alpha, et qui doit la tester ?
- Ce qu’il faut retenir pour vos projets
- Questions fréquentes
Que contient l’annonce de sécurité du 21 octobre ? #
L’annonce publiée sur le blog officiel de Node.js, mise à jour le 14 octobre, prévient que de nouvelles versions des lignes 26.x, 24.x et 22.x sortiront « on or shortly after » le mercredi 21 octobre 2026.
À lire Comment nettoyer et dédoublonner une base de prospects sans perdre de leads ?
Pour chacune des trois lignes, la vulnérabilité la plus grave corrigée est classée HIGH. Comme d’habitude, le projet ne publie ni la nature des failles ni le nombre de correctifs avant la sortie : c’est la règle de la divulgation coordonnée, pour ne pas donner une longueur d’avance aux attaquants.
L’annonce rappelle aussi un point que beaucoup d’équipes oublient : les versions arrivées en fin de vie sont toujours concernées par les failles découvertes, mais elles ne reçoivent plus de correctif.
Comment se préparer d’ici mercredi ? #
Le travail se fait maintenant, pas le jour de la sortie. Commencez par faire l’inventaire des versions de Node.js réellement utilisées : serveurs, conteneurs, fonctions serverless, runners de CI, postes des développeurs. Les images Docker figées sur une version précise sont souvent les plus en retard.
Vérifiez ensuite que votre chaîne de mise à jour fonctionne. Si vos images de base sont reconstruites automatiquement, assurez-vous que la nouvelle version sera bien récupérée. Si vous passez par un gestionnaire de versions comme nvm ou un fichier .nvmrc, prévoyez qui mettra à jour la version cible.
À lire Comment vérifier la couverture réseau à l’étranger avant d’acheter ?
Enfin, réservez un créneau de tests après la sortie. Une version de sécurité ne casse pas l’API en principe, mais un correctif peut modifier un comportement limite sur lequel votre code s’appuyait sans le savoir. Le plus sûr reste de déployer d’abord en préproduction.
Pour suivre l’annonce en temps réel, le projet recommande de s’abonner à la liste de diffusion nodejs-sec, et renvoie vers sa politique de sécurité.
Pourquoi octobre 2026 est un mois charnière pour Node.js ? #
Ces correctifs tombent au moment où le projet change de calendrier. Le billet « Evolving the Node.js Release Schedule », signé par l’équipe des releasers, détaille le nouveau modèle.
Node.js 26, sortie en avril 2026, est la dernière ligne de l’ancien modèle. Elle doit passer en LTS en octobre 2026, puis en maintenance en octobre 2027, avant sa fin de vie en avril 2029.
À lire NodeJS JavaScript : comprendre le duo qui fait tourner le web moderne
Node.js 27 inaugure le nouveau rythme. Sa phase alpha commence en octobre 2026, la version 27.0.0 est prévue en avril 2027, son passage en LTS en octobre 2027 et sa fin de vie en avril 2030.
Qu’est-ce qui change avec une seule version majeure par an ? #
Jusqu’ici, Node.js publiait deux versions majeures par an, et seules les versions paires devenaient LTS. Désormais, il n’y aura plus qu’une version par an, et chaque version deviendra LTS. La numérotation suivra l’année de la première version Current : 27.0.0 en 2027, 28.0.0 en 2028.
Le cycle se découpe en quatre temps : six mois d’alpha d’octobre à mars, six mois de version Current d’avril à octobre, puis 30 mois de LTS. Au total, une version est supportée 36 mois à partir de sa première sortie Current.
Les raisons données par l’équipe sont pragmatiques. Le calendrier actuel a dix ans, les versions impaires sont peu adoptées, la distinction paire/impaire déroute les nouveaux venus, et gérer les correctifs de sécurité sur quatre ou cinq lignes actives devient difficile à tenir pour des bénévoles.
À quoi sert la phase alpha, et qui doit la tester ? #
L’alpha remplace en quelque sorte les anciennes versions impaires, avec une différence : les changements cassants (semver-major) y sont autorisés. Les versions alpha seront signées, taguées et testées avec CITGM, l’outil qui fait tourner les tests de grands paquets open source sur la future version.
Ce n’est pas une nightly : les builds automatiques non testés depuis la branche main restent disponibles à part. Et ce n’est pas fait pour la production. Le public visé est clair : les auteurs de bibliothèques et les pipelines de CI.
Le conseil de l’équipe est direct : intégrer l’alpha dans sa CI le plus tôt possible, car en ne testant que les versions LTS, on découvre les régressions en même temps que ses utilisateurs.
Ce qu’il faut retenir pour vos projets #
À court terme, la priorité est la mise à jour de sécurité du 21 octobre sur toutes les lignes que vous utilisez. À moyen terme, si vous maintenez une bibliothèque, ajoutez une cible 27.0.0-alpha à votre matrice de tests.
Pour une application, la stratégie devient plus simple : passer chaque année à la nouvelle LTS d’octobre, avec un recouvrement suffisant entre deux versions pour migrer sans précipitation.
Questions fréquentes #
Quelles versions de Node.js reçoivent les correctifs du 21 octobre ?
Les lignes 26.x, 24.x et 22.x. Les versions en fin de vie restent vulnérables et ne sont pas corrigées.
Faut-il utiliser l’alpha de Node.js 27 en production ?
Non. L’équipe Node.js précise qu’elle n’est pas destinée à la production : elle sert aux tests des bibliothèques et des pipelines de CI.
Combien de temps une version de Node.js sera-t-elle supportée ?
Avec le nouveau modèle, 36 mois à partir de la première version Current, dont 30 mois de LTS.
