Node.js : correctifs de juillet, et les versions qui n'en recevront plus
Node.js publie ce 29 juillet onze correctifs de sécurité pour ses branches 22, 24 et 26. Node 20 n'en reçoit plus depuis avril. Ce qu'il faut vérifier sur vos applications.
Après deux reports, Node.js publie ce mercredi 29 juillet ses correctifs de sécurité de juillet : onze failles corrigées dans les trois branches encore maintenues, 22, 24 et 26. C'est une mise à jour de routine, mais elle rappelle un point que beaucoup d'entreprises ignorent : leurs applications tournent peut-être sur une version de Node.js qui ne reçoit plus aucun correctif. Node 20, très répandue, n'est plus maintenue depuis le 30 avril.
Node.js, de quoi parle-t-on ?
Node.js est le moteur qui fait tourner, côté serveur, une grande partie des applications web modernes : sites marchands, extranets, interfaces de programmation, outils internes. Si votre application est écrite en JavaScript ou en TypeScript, il y a de bonnes chances qu'elle tourne sur Node.js, comme notre propre site.
Node.js fonctionne par branches numérotées. Chaque branche paire bénéficie d'une longue période de maintenance, puis atteint sa « fin de vie » : à partir de là, plus aucun correctif de sécurité n'est publié pour elle.
Ce que contient la publication de juillet
D'après l'avis publié sur le site de Node.js :
- la publication était prévue le lundi 27 juillet, reportée au 28 pour des tests supplémentaires, puis au 29 en raison de problèmes d'infrastructure ;
- elle concerne les branches 26, 24 et 22, avec les versions 26.5.1, 24.18.1 et 22.23.2 ;
- elle corrige onze failles : trois de gravité élevée, cinq moyennes et trois faibles ;
- elle met aussi à jour deux composants internes qui traitent les requêtes web, undici et llhttp ;
- l'avis rappelle que les versions en fin de vie sont toujours concernées par les failles corrigées, sans recevoir de correctif.
Le vrai sujet : les versions en fin de vie
D'après le calendrier officiel de Node.js, la branche 20 a atteint sa fin de vie le 30 avril 2026, et la branche 18 un an plus tôt. Or ces versions restent très présentes dans les applications en production, souvent parce qu'elles ont été installées au moment du développement et que personne n'y a touché depuis.
Une application qui tourne sur Node 20 ou plus ancien est affectée par les failles corrigées ce mois-ci, et elle ne sera pas corrigée. Elle ne le sera pas non plus le mois prochain, ni le suivant. Le risque ne se voit pas : l'application fonctionne parfaitement, jusqu'au jour où une faille connue est exploitée.
La fin de vie a aussi des effets indirects. npm 12, sorti le 8 juillet, ne fonctionne qu'avec des versions récentes des branches 22, 24 et 26, comme nous le relevions dans notre article sur npm 12. Et les cadres de développement suivent : Next.js, dont les correctifs de juillet ne concernent que ses branches maintenues, exige lui aussi des versions récentes de Node.js. Rester en arrière sur Node.js, c'est finir par ne plus pouvoir mettre à jour le reste.
Ce qu'il faut vérifier
- La version de Node.js de chaque application en production : site, extranet, outils internes, tâches automatiques. Votre prestataire doit pouvoir répondre en quelques minutes.
- Pour celles qui sont sur une branche maintenue (22, 24, 26) : la mise à jour de juillet est-elle planifiée, testée, déployée ?
- Pour celles qui sont en fin de vie (20 ou plus ancien) : quel est le plan de migration, et à quelle date ? Passer d'une branche à une autre demande des tests, parfois des adaptations du code ; ce n'est pas une simple mise à jour.
- Les images de serveurs et conteneurs : la version de Node.js y est souvent figée. Une mise à jour de l'application ne change rien si l'image n'est pas reconstruite.
Une maintenance qui se planifie
Node.js publie ses correctifs à date annoncée, comme Next.js depuis ce mois-ci. C'est une bonne chose : la sécurité devient prévisible. Mais elle suppose une organisation : quelqu'un qui surveille les avis, des tests automatiques pour valider les mises à jour, et un créneau régulier pour les appliquer. Et, tous les deux à trois ans par application, une migration vers une branche plus récente.
C'est ce que couvre la maintenance de nos logiciels, avec une réponse sous 24 heures ouvrées. Les prix sont affichés sur la page Tarifs. Si vous ne savez pas sur quelle version tournent vos applications, un rendez-vous de 30 minutes, gratuit, permet de dresser la liste et le plan.