Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Principaux enseignements
- Lorsqu'une version de Node.js arrive en fin de vie, le développeur en amont cesse de vérifier si de nouvelles vulnérabilités la concernent.
- À partir de Node.js 27, le projet publie une version majeure par an, et chaque branche de version devient une version LTS.
- Les outils d'IA détectent de véritables bogues dans Node.js, mais les signalements en double submergent désormais les bénévoles chargés du triage.
- Les équipes qui ne peuvent pas effectuer la mise à niveau dans les délais prévus ont besoin d'un environnement d'exécution corrigé, et non pas d'espérer que rien ne soit divulgué.
Une application Node.js ne cesse pas de fonctionner lorsque sa version arrive en fin de vie. Le projet en amont cesse simplement de s'en occuper. Et comme l'a expliqué James Snell, membre du Comité de pilotage technique de Node.js, lors d'une récente discussion informelle avec TuxCare, cette différence est bien plus importante qu'il n'y paraît.
« Pas de rétroportage, pas de correctifs », a-t-il déclaré. Lorsqu’un nouveau rapport de vulnérabilité est signalé, l’équipe ne vérifie même pas s’il concerne une gamme de produits en fin de vie. Un service peut sembler fonctionner parfaitement en production, alors que les travaux de sécurité menés en amont ont discrètement évolué sans le prendre en compte.
C'était l'un des nombreux moments de franchise de l'épisode « Keepers of the Runtime », au cours duquel Snell s'est entretenu avec Chris DeMars, responsable senior de la promotion des développeurs chez TuxCare. Pas de diapositives, pas de démonstration de produit. Ils ont abordé les raisons pour lesquelles Node.js passe à une version majeure par an, l'impact des rapports de sécurité générés par l'IA sur une équipe de sécurité bénévole, et l'ampleur du travail humain qui se cache derrière une mise à jour de sécurité en apparence routinière. Voici ce qui importe le plus si vous utilisez Node.js en production, même s’il vaut la peine de prendre une demi-heure pour regarder l’intégralité de l’enregistrement.
La fin de vie de Node.js marque la fin des efforts de sécurité en amont
La description que Snell a donnée de la « fin de vie » était sans détour. Dès qu’une version majeure n’est plus prise en charge, plus rien n’y est intégré. Ni correctifs de sécurité, ni corrections de bogues courantes, ni rétroportages depuis des branches plus récentes. « D’autres le feront peut-être, mais pas nous », a-t-il déclaré à propos du test des anciennes versions face à de nouveaux rapports. « Une fois qu’une version est en fin de vie, elle ne fait plus partie de nos priorités. »
Les recommandations du projet concernant les vulnérabilités des versions en fin de vie (EOL) vont dans le même sens. Une ancienne version peut très bien être affectée par une vulnérabilité révélée dans une version encore maintenue, mais le développeur en amont n'effectuera généralement pas d'analyse de l'ancienne branche pour confirmer l'impact, et encore moins pour développer un correctif.
Réfléchissez à ce que cela implique pour votre scanner. Depuis 2025, les nouvelles vulnérabilités CVE de Node.js répertorient par défaut les versions en fin de vie (EOL) comme étant concernées, sauf indication contraire de la part du projet. L'avertissement reste donc visible, mais personne en amont n'a confirmé la présence de la faille sur votre version, et personne en amont ne travaille à la mise au point d'un correctif.
Un environnement d'exécution en fin de vie n'est pas non plus isolé. Node.js intègre des composants tels que V8 et OpenSSL, et Snell a souligné que des failles « zero-day » de V8 apparaissent sans cesse, y compris des échappements de sandbox. Toutes les failles de V8 côté navigateur n’affectent pas nécessairement Node.js, mais quelqu’un doit déterminer lesquelles le font, et sur une version en fin de vie, ce n’est pas l’éditeur qui s’en charge. Parallèlement, les bibliothèques et les outils cessent progressivement de prendre en charge les anciennes versions de Node.js, ce qui rend chaque mois un peu plus difficile toute mise à niveau reportée.
Cela ne signifie pas pour autant que chaque déploiement en fin de vie soit automatiquement exploitable. L'exposition dépend de la vulnérabilité spécifique, de la configuration et des chemins d'exécution accessibles. Ce qui change en fin de vie, c'est que les réponses et les correctifs fournis par l'éditeur cessent d'arriver, ce qui oblige votre équipe à mener davantage d'analyses au moment même où ses options se réduisent.
Pourquoi Upstream ne prolongera pas la durée de vie des anciennes versions
Il arrive que des utilisateurs demandent aux responsables en amont de maintenir une ancienne version un peu plus longtemps. La réponse tient à la fois aux personnes et aux machines. Node.js est principalement maintenu par des bénévoles. Quelques contributeurs sont parrainés, mais selon M. Snell, presque tous ceux qui publient des versions, effectuent des rétroportages et apportent leur contribution le font sur leur temps libre. « Nous n’allons pas simplement assurer le support de tout indéfiniment », a déclaré M. Snell. « Nous ne pouvons pas. C’est impossible. »
Vient ensuite la CI. Selon Snell, un cycle complet de CI couvre environ 55 combinaisons de plateformes, d’architectures et de systèmes d’exploitation, avec quelque 7 800 tests pour chacune, et un seul cycle peut prendre jusqu’à une heure. Les entreprises mettent cette infrastructure à disposition, et sa capacité est fixe. Multipliez cela par chaque ancienne version, et les calculs deviennent vite impossibles. Comme l’explique Snell : « La fin de vie est la fin de vie, tout simplement parce que nous ne pouvons physiquement pas consacrer les ressources nécessaires à sa maintenance. »
C'est un point de vue légitime ; difficile de le contester. Cela laisse toutefois une lacune, et cette lacune incombe à ceux qui utilisent encore l'ancienne version.
Pourquoi Node.js passe à une version majeure par an
C'est ce même problème de capacité qui explique le nouveau calendrier de publication. L'ancien calendrier était un compromis né lors de la réunification d'io.js : des versions impaires à courte durée de vie, prises en charge pendant environ huit mois seulement, afin que les auteurs de bibliothèques et de frameworks puissent anticiper les évolutions, ainsi que des versions paires qui devenaient des versions LTS (Long-Term Support) pour les entreprises.
Les données de téléchargement recueillies sur dix ans ont révélé une réalité bien différente. « En réalité, personne n’utilisait les versions à court terme », a déclaré Snell. Les entreprises effectuaient déjà une mise à niveau environ une fois par an, voire moins. De leur côté, les responsables de la maintenance devaient parfois jongler avec quatre ou cinq branches de version actives simultanément, et chaque correctif de sécurité devait être retracé à travers des branches qui avaient évolué de manière divergente.
Conformément au calendrier officiel de publication de Node.js, Node.js 27 est la première version de ce nouveau modèle. Chaque année, une version majeure est publiée en avril, puis élevée au statut LTS en octobre, de sorte que chaque branche de version devient finalement LTS. Un canal Alpha prend le relais du rôle de test précoce que jouaient auparavant les versions impaires, et après six mois en Alpha, chaque branche bénéficie de 36 mois de support, depuis sa première version « Current » jusqu'à la fin de vie. Le résumé des avantages présenté par Snell était simple : beaucoup moins de branches à gérer, avec environ trois en cours à la fois.
| Ligne de libération | Début de la phase Alpha | Première version | Passe en LTS | Fin de vie |
|---|---|---|---|---|
| Node.js 26 (dernière version sur l'ancien modèle) | Sans objet | Mai 2026 | Octobre 2026 | Avril 2029 |
| Node.js 27 | Octobre 2026 | Avril 2027 | Octobre 2027 | Avril 2030 |
| Node.js 28 | Octobre 2027 | Avril 2028 | Octobre 2028 | Avril 2031 |
Si votre équipe ne déploie déjà que des versions LTS, cela n’entraîne que peu de changements, hormis la numérotation des versions. Si vous développez des produits sur Node.js, Snell conseillait de ne plus attendre le mois d’avril pour découvrir ce qui ne fonctionnait plus. Les changements majeurs et les fonctionnalités obsolètes sont publiés sur main en permanence. Ajoutez une tâche de test de fonctionnement dans l’environnement de CI qui s’exécute sur les prochaines versions alpha sans bloquer les fusions, et chargez quelqu’un de lire réellement les résultats. Les versions alpha ne sont pas destinées à la production, mais détecter un problème trois ou quatre mois à l’avance revient bien moins cher que de le découvrir pendant une fenêtre de migration.
Que se passe-t-il entre la publication d'un rapport de sécurité Node.js et la mise en place d'un correctif ?
Node.js recueille les signalements de vulnérabilités via HackerOne. Un triageur vérifie d'abord si le comportement signalé est bien réel, puis détermine s'il enfreint une limite de sécurité définie par le modèle de menace du projet.
Ce deuxième critère passe facilement inaperçu. Le modèle de confiance de Node est sans appel : si le code s'exécute, il est considéré comme fiable. Une erreur de segmentation que l'on ne peut déclencher qu'en exécutant son propre code localement est probablement un bug ordinaire, corrigé de manière transparente. Tout ce qui est accessible via une entrée distante non fiable, comme l'exécution de code à distance ou un déni de service à distance, est considéré comme une vulnérabilité.
Ces correctifs sont développés, révisés et intégrés dans une branche privée de Node, et la version de sécurité est générée à partir de là. Ce n’est qu’après sa publication que les modifications sont transférées dans le dépôt public. Cela permet de réduire à presque zéro le délai entre la divulgation et la disponibilité d’un correctif pour les versions prises en charge, mais cela signifie également que le compte à rebours commence dès la publication d’un avis de sécurité. La version du 21 octobre 2026 en est un bon exemple : dix CVE répartis sur les branches 22.x, 24.x et 26.x, dont quatre classés « Élevé ». L’article de TuxCare intitulé « 10 CVE Node.js, une vulnérabilité RCE dans Brotli et que faire si votre version est en fin de vie » explique en détail ce que cela implique pour toute personne utilisant une branche en fin de vie. La prochaine vague est d’ailleurs déjà prévue. Node.js a annoncé une nouvelle mise à jour de sécurité pour le 11 novembre 2026, ou peu après, couvrant à nouveau les versions 22.x, 24.x et 26.x, la vulnérabilité la plus grave étant classée « Élevée ». L’avis précise que les versions en fin de vie sont toujours concernées lorsqu’une mise à jour de sécurité est publiée.
L'IA détecte de véritables bogues et engorge la file d'attente de triage
C'est là que Snell s'est montré le plus enthousiaste. La détection assistée par IA fonctionne. « Elle permet bel et bien de repérer de véritables bogues », a-t-il déclaré. La précision n'est pas le principal problème. C'est le volume.
Les chercheurs qui utilisent des outils similaires ont tendance à découvrir le même bug au même moment et à le signaler indépendamment les uns des autres. Snell a expliqué recevoir 10 ou 20 signalements concernant un même problème, d’autres continuant d’arriver pendant que le correctif était en cours d’élaboration, et une longue traînée de signalements affluant encore après la divulgation. Lors d’une récente période de triage, il a estimé que « probablement neuf signalements sur dix étaient des doublons » – il s’agit d’une estimation basée sur cette charge de travail, et non d’un taux mesuré.
La mise à jour de sécurité du deuxième trimestre 2026 de la Fondation OpenJS confirme cette tendance. Node.js avait reçu 352 signalements via HackerOne au cours des deux années précédant ce trimestre. Le nombre de signalements a ensuite été multiplié par 4,6 en février 2026 après l’arrivée d’outils d’analyse assistés par IA, et le mois de mars à lui seul en a enregistré 65. Au moment de la discussion, a indiqué M. Snell, Node.js avait déjà publié des correctifs pour plus de 50 vulnérabilités en 2026, un record.
Ses conseils aux chercheurs étaient concrets. Lisez la politique de sécurité et le modèle de menaces du projet. Consultez les rapports rendus publics par HackerOne pour vérifier si le problème a déjà été traité. Et si votre outil de détection identifie 20 vulnérabilités potentielles, n’envoyez pas 20 rapports d’un seul coup. Classez-les par ordre de priorité et envoyez d’abord les plus critiques.
Le travail qui n'apparaît pas dans les notes de mise à jour
Snell n'est pas arrivé à Node.js à la suite d'un plan d'envergure. En 2013, alors qu'il travaillait chez IBM, il a découvert un bug dans lequel Node traitait une méthode HTTP corrompue comme P?T en y voyant une véritable méthode plutôt que de la rejeter. En l'absence de processus de signalement des failles de sécurité à l'époque, il a ouvert un ticket public, s'est entendu dire qu'il ne comprenait pas le fonctionnement de ce type de logiciel, a corrigé le problème lui-même, puis s'est retiré. La branche io.js l'a ramené dans le giron d'IBM lorsque celle-ci a eu besoin d'un responsable technique pour tout ce qui concernait Node, et il a rejoint le TSC vers mars 2015.
Le quotidien est moins prestigieux que ne le laisse supposer son titre. Ses matinées commencent par une heure, voire plus, consacrée aux notifications GitHub, qui peuvent parfois atteindre 800 ou 900 par jour. La relecture de code lui prend encore plus de temps. « Je lis chaque ligne de chaque pull request, même les plus volumineuses », explique-t-il, qu’il s’agisse de dix lignes ou de 20 000, souvent en deux ou trois lectures. L’IA rédige désormais la plupart de ses tests, mais elle n’a pas remplacé son jugement.
Snell a également réfuté l'idée selon laquelle Node.js disposerait d'une feuille de route produit. « Il n’y a pas de chef de produit. Il n’y a même pas de chef de projet. » Personne ne peut acheter une fonctionnalité pour Node. Une fois la validation par intégration (CI) effectuée, une pull request peut être acceptée après deux validations au bout d’au moins 48 heures, ou après une seule validation au bout d’une semaine, à condition que personne ne s’y oppose. Ainsi, si vous souhaitez que Node intègre une fonctionnalité, son conseil est d’ouvrir une pull request et de la développer vous-même, plutôt que d’exiger que des bénévoles la développent gratuitement.
Ce que cela implique pour les équipes qui utilisent encore d'anciennes versions de Node.js
Commencez par ce qui est réellement déployé. Pas ce qu'indique le Dockerfile actuel ni ce que précise le ticket de migration, mais les versions de Node.js en cours d'exécution en production, y compris les services que personne n'a modifiés depuis un certain temps. Comparez-les au calendrier de publication de Node.js, signalez celles dont la fin de vie (EOL) est déjà dépassée, et attribuez un responsable à chacune d’entre elles. Node.js 20 a atteint sa fin de vie le 30 avril 2026, et Node.js 22 suivra en avril 2027 ; ce problème ne concerne donc pas uniquement les équipes utilisant des versions très anciennes.
Si vous pouvez effectuer une mise à niveau dès maintenant, n'hésitez pas. Opter pour une version LTS prise en charge est la solution la plus simple, et il vaut mieux procéder à des mises à niveau régulières pendant l'exploitation plutôt que de devoir faire face à une situation d'urgence tous les deux ou trois ans.
Certaines applications ne peuvent pas suivre ce calendrier. Imaginez un service de paiement qui doit rester sur Node.js 18 parce qu’un module natif ne fonctionne plus avec les versions plus récentes de V8, la migration étant subordonnée à une réécriture par le fournisseur prévue dans deux trimestres. Dans ce genre de situation, dire « on mettra à jour plus tard » ne constitue pas une stratégie de sécurité, à moins que l’ancien environnement d’exécution puisse encore bénéficier de correctifs.
C’est précisément cette lacune que comble le service « Endless Lifecycle Support » (ELS) de TuxCare pour Node.js. Faisant partie de l’offre ELS pour les environnements d’exécution, ce service intègre les correctifs de sécurité dans les versions de Node.js en fin de vie (EOL) couvertes par le contrat de niveau de service (SLA) et les fournit sous forme de mises à jour de paquets. Ainsi, vos applications continuent de fonctionner sur l’environnement d’exécution pour lequel elles ont été conçues, tandis que vous menez à bien la migration selon votre propre calendrier. Il suffit de redémarrer les processus Node.js concernés après une mise à jour pour qu’ils intègrent le runtime corrigé. La couverture remonte jusqu’à Node.js 10 sur Enterprise Linux et s’étend également à Ubuntu, Debian et Alpine Linux, les versions prises en charge variant selon le système d’exploitation ; veuillez donc consulter la matrice des versions dans la documentation. Cela ne dispense pas de procéder à une mise à niveau à terme. Ce service couvre la période comprise entre le jour où le développeur en amont cesse de corriger une version et le jour où vous pouvez la retirer en toute sécurité.
Inutile non plus d'attendre un appel commercial. Achetez ELS for Runtimes en ligne, installez-le et remettez vos versions de Node.js en fin de vie (EOL) sur un flux de correctifs.
Foire aux questions
Que se passe-t-il lorsqu'une version de Node.js arrive en fin de vie ?
Upstream suspend toutes les validations sur cette branche, y compris les correctifs de sécurité, et ne vérifie pas si les vulnérabilités récemment signalées l'affectent. À partir de ce moment-là, le risque incombe à l'équipe qui l'utilise.
Quand sortira Node.js 27 ?
La version alpha de Node.js 27 a été lancée en octobre 2026. La première version « Current » est prévue pour avril 2027, avec une mise en LTS en octobre 2027 et une fin de vie en avril 2030.
Peut-on continuer à utiliser Node.js 18 ou Node.js 20 après la fin de leur cycle de vie ?
Oui. Les services d'assistance commerciale, tels que l'offre « Endless Lifecycle Support for Node.js » de TuxCare, continuent de fournir des correctifs de sécurité pour les versions en fin de vie (EOL) couvertes pendant que vous planifiez votre mise à niveau, à condition que vous installiez les mises à jour et que vous redémarriez les processus concernés.
Regardez l'intégralité de cette discussion informelle
La rediffusion comprend les interventions qui n'ont pas été reprises dans cet article, ainsi que la session de questions-réponses en direct consacrée aux signalements en double et à la fidélisation des bénévoles. Regardez « Keepers of the Runtime » avec James Snell et Chris DeMars.
Et si une partie de votre pile repose encore sur une version de Node.js pour laquelle le développeur en amont a cessé de publier des correctifs, n’attendez pas que le prochain avis de sécurité prenne la décision à votre place. Optez pour ELS for Runtimes et continuez à bénéficier des correctifs de sécurité pour les versions couvertes tout en effectuant la mise à niveau à votre rythme.
