Fin de prise en charge de Node.js 18 et options de migration

Principaux enseignements

• Node.js 18 a atteint sa fin de vie le 30 avril 2025 et ne bénéficie plus de mises à jour de sécurité ni de corrections de bogues de la part du projet Node.js.
• Le projet considère que toutes les versions arrivées en fin de vie sont concernées dès qu'une mise à jour de sécurité est publiée ; par conséquent, le nombre de failles non corrigées dans Node.js 18 augmente selon le calendrier prévu par le projet, et non selon le vôtre.
• Node.js 24 est aujourd'hui la seule version LTS encore en développement. Node.js 22 est déjà en phase de maintenance LTS et arrivera en fin de vie le 30 avril 2027, ce qui en fait une cible de migration peu intéressante.
• Le support à cycle de vie illimité de TuxCare permet de maintenir Node.js 18 à jour avec les correctifs contre les vulnérabilités connues, tandis que les équipes planifient et testent la migration à un rythme réaliste.

Presque personne ne choisit d'utiliser une version en fin de vie. Les équipes en arrivent là parce que les demandes de mise à jour sont sans cesse reléguées au second plan par les tâches de livraison, et parce que tout semble fonctionner correctement. Node.js 18 a atteint sa fin de vie le 30 avril 2025 – il y a plus d'un an – et n'a reçu depuis lors aucun correctif de sécurité, aucune correction de bogue ni aucun support officiel de la part du projet Node.js.

Ce qui pose problème aux équipes, c'est la gestion de ces versions. La position officielle du projet Node.js est que les versions en fin de vie sont concernées dès qu'une mise à jour de sécurité est publiée, que quelqu'un les teste à nouveau ou non. Votre surface d'exposition non corrigée augmente donc à chaque fois que le projet publie un avis de sécurité, selon un rythme que vous ne contrôlez pas.

Ce guide présente le calendrier de fin de vie (EOL) de Node.js 18, indique quelle version vous devriez réellement cibler en 2026 – ce n'est probablement pas celle qui vient spontanément à l'esprit – et explique comment rester à jour si la migration ne peut pas être menée à bien ce trimestre.

Comprendre la fin de vie de Node.js 18

Il est utile de savoir comment le groupe de travail sur les versions de Node.js organise concrètement la prise en charge. Il existe trois phases de prise en charge, et la « fin de vie » correspond au statut atteint par une ligne de versions une fois ces phases terminées.

Actuel : Une nouvelle version majeure reste dans la branche « Current » pendant environ six mois, ce qui laisse aux auteurs de bibliothèques le temps d’y ajouter la prise en charge. Le projet recommande que les applications de production n’utilisent que les versions Active LTS ou Maintenance LTS.

LTS active : Au bout d’environ six mois, les versions paires sont promues au statut « LTS actif » pendant environ 12 mois. Cette phase ne se limite pas aux correctifs d’urgence : elle inclut de nouvelles fonctionnalités, des corrections de bogues et des mises à jour que l’équipe de publication a vérifiées et jugées appropriées et stables pour cette branche. Les branches impaires ne sont jamais promues ; c’est pourquoi les versions 23 et 25 sont passées du statut « Actuelle » à la fin de vie sans passer par une phase LTS.

Maintenance : La phase LTS active est suivie d'une période de maintenance d'environ 18 mois, limitée aux corrections de bogues critiques et aux mises à jour de sécurité. De nouvelles fonctionnalités ne sont ajoutées que très rarement, et généralement uniquement lorsqu'elles facilitent la migration vers une version ultérieure.

Cela représente environ 36 mois entre la sortie initiale et la fin de vie, dont environ 30 mois sous couverture LTS.

Un changement à prendre en compte : ce modèle « pair/impair » ne s'applique que jusqu'à Node.js 26. À partir de Node.js 27, Node.js passe à un seul cycle de publication majeur par an, et chaque version majeure sera promue au statut LTS (Long-Term Support) après sa phase « Current ». Si vous choisissez une version cible aujourd'hui, la phase est plus importante que le numéro de version : une version déjà en phase de maintenance est en voie de retrait, même si elle semble récente.

Fin de vie de Node.js 18 : dates clés

Node.js 18 (nom de code « Hydrogen ») a été publié le 19 avril 2022. Il est passé en phase « Active LTS » le 25 octobre 2022, puis en phase de « Maintenance » le 18 octobre 2023, avant d'atteindre sa fin de vie le 30 avril 2025.

 

Par où commencer : Vérifiez bien ce que vous utilisez réellement avant de planifier quoi que ce soit, car dans la plupart des environnements, il n’y a pas qu’une seule version. Exécutez la commande `node -v` sur chaque hôte, puis vérifiez vos fichiers Dockerfile, vos images CI et tous les paramètres d’exécution gérés dans Lambda, App Runner ou la plateforme de votre choix.

Risques liés à Node.js 18 après la fin de vie du produit

Continuer à utiliser Node.js 18 après la fin de son cycle de vie n'entraîne pas de perturbations dès le premier jour, et c'est précisément pour cette raison que les systèmes restent en place. Tout continue de fonctionner. Les API répondent toujours. Personne ne reçoit d'alerte.

Ce qui a changé, c'est que les correctifs ont cessé d'être publiés alors que de nouvelles vulnérabilités continuaient d'être découvertes. Les risques énumérés ci-dessous s'accumulent, et chacun d'entre eux coûte moins cher à gérer lors d'une fenêtre de mise à jour planifiée que lors d'un incident. Tant que Node.js 18 était pris en charge, il bénéficiait de correctifs de sécurité au même titre que toutes les autres versions maintenues. Ces publications ont pris fin en avril 2025, et le projet Node.js ne publiera plus de correctifs pour cette version.

Exposition croissante aux vulnérabilités CVE

La position officielle du projet constitue un argument utile si vous devez justifier ce travail en interne : les versions en fin de vie sont toujours concernées lorsqu’une mise à jour de sécurité est publiée. Node.js ne procède pas à de nouveaux tests sur les versions en fin de vie ; ses avis de sécurité ne mentionnent donc que les versions prises en charge. Cependant, les chemins de code vulnérables sont toujours présents dans la version 18, et aucun correctif officiel n’est prévu pour ceux-ci.

La mise à jour de sécurité du 13 janvier 2026 en est un bon exemple. Elle a corrigé huit vulnérabilités sur l'ensemble des gammes prises en charge, dont les quatre suivantes :

• CVE-2025-55131 (Élevé) – Une condition de concurrence liée à un délai d'expiration empêche Buffer.alloc et les tableaux typés d'être remplis de zéros, exposant ainsi de la mémoire non initialisée. Accessible via le module vm avec des délais d'expiration, ce qui est particulièrement important lorsque du code semi-fiable s'exécute.
• CVE-2025-59465 (Élevé) – Une trame HTTP/2 HEADERS mal formée contenant des données HPACK non valides provoque le plantage du processus en raison d'une erreur de socket TLS non gérée.
• CVE-2025-59466 (Moyenne) – Une erreur « Taille maximale de la pile d'appels dépassée » devient impossible à intercepter lorsque async_hooks est actif, contournant ainsi process.on('uncaughtException'). La portée de cette faille est plus étendue qu'il n'y paraît à première vue : AsyncLocalStorage s'appuie sur async_hooks, ce qui signifie que Next.js, les composants serveur React et la plupart des agents APM sont concernés.
• CVE-2026-21637 (Risque moyen) – Les exceptions levées par les callbacks TLS PSK ou ALPN contournent les gestionnaires d'erreurs, ce qui entraîne un déni de service et une fuite de descripteurs de fichiers.

Ces correctifs ont été intégrés dans les versions 20.20.0, 22.22.0, 24.13.0 et 25.3.0. Il n'existe pas d'équivalent pour la version 18.x, et il n'y en aura pas.

Remarque concernant les outils : Le projet Node.js gère le paquet is-my-node-vulnerable, qui compare la version que vous avez installée à la base de données de sécurité de Node.js. Exécutez la commande npx is-my-node-vulnerable. Sachez toutefois comment cet outil se comporte avec un environnement d'exécution en fin de vie (EOL) : au lieu de répertorier les CVE individuellement, il signale que la version est en fin de vie et la considère par défaut comme vulnérable, car les versions EOL ne sont pas mises à jour par rapport aux derniers correctifs de sécurité. Pour obtenir des détails par CVE et connaître l'état des correctifs sur les versions prises en charge par TuxCare, utilisez le CVE Tracker.

 

Défauts de conformité

Un runtime EOL échoue rarement à lui seul à un audit. Il a pour effet de supprimer le moyen le plus simple de respecter les contrôles de gestion des vulnérabilités prévus par la norme PCI DSS, HIPAA, RGPDet ISO 27001, qui exigent généralement que vous identifiiez les vulnérabilités connues et que vous y remédiiez dans un délai défini.

La norme PCI DSS est celle qui impose les exigences les plus précises en matière de délais. L'exigence 6.3.3 prévoit que les correctifs de sécurité critiques soient installés dans un délai d'un mois à compter de leur publication. Lorsque le projet en amont a cessé de publier des correctifs pour votre environnement d'exécution, vous ne pouvez plus satisfaire à cette exigence par l'application de correctifs ; vous devez alors démontrer la mise en place de mesures de contrôle compensatoires.

Il existe également un problème lié aux scanners qui surprend souvent les utilisateurs. Le projet Node.js émet désormais lui-même des CVE pour les versions en fin de vie, classées comme « non prises en charge » lorsqu’elles sont attribuées sous le code CWE-1104, qui correspond à l’utilisation de composants tiers non maintenus. Node.js 18 peut donc apparaître comme un problème détecté par des outils tels que npm audit ou Snyk, simplement parce qu’il s’agit d’une version en fin de vie, indépendamment de tout bug spécifique.

Si vous faites partie du périmètre d'audit : choisissez dès maintenant votre stratégie : mise à niveau, application de correctifs commerciaux ou mise en place de contrôles compensatoires documentés. Ces trois options sont défendables. En revanche, découvrir lors de l'audit sur site que vous n'en disposez d'aucune ne l'est pas.

Dépendances et rupture de l'écosystème

Les applications Node.js modernes s'appuient sur une vaste arborescence de dépendances, et celle-ci évolue sans crier gare. Les paquets, les frameworks et les services cloud abandonnent les anciens environnements d'exécution selon leur propre calendrier. AWS, par exemple, a mis fin au support de Node.js 18.x dans l’AWS Cloud Development Kit le 30 novembre 2025, ce qui concerne la CLI du CDK, la bibliothèque construct et les projets associés tels que JSII, Projen et CDK8s.

Le schéma est prévisible. Les nouvelles versions des bibliothèques cessent de prendre en charge les anciennes versions de Node.js ; les équipes fixent donc les versions pour assurer la continuité du fonctionnement, mais l’arborescence ainsi figée finit elle aussi par ne plus être prise en charge. Plus on s’attarde, plus la dette technique s’accumule, jusqu’à ce que les mises à jour de routine nécessitent d’abord une mise à niveau de l’environnement d’exécution.

Exemple : Une équipe utilisant une API Node.js 18 doit corriger une vulnérabilité dans une bibliothèque de journalisation. La version corrigée nécessite Node.js 20 ou une version ultérieure. La mise à niveau de l'environnement d'exécution n'étant pas prévue, l'équipe continue d'utiliser la version vulnérable. Le correctif existe, mais elle ne peut toujours pas l'appliquer.

C'est là que réside le véritable risque lié à la fin de vie (EOL). Il se manifeste généralement via l'arborescence des dépendances plutôt que par le biais de l'environnement d'exécution lui-même.

Risque opérationnel et débogage plus complexe

Une fois la fin de vie atteinte, le projet Node.js cesse de publier des correctifs et de fournir une assistance technique pour cette version, et l'attention de la communauté se porte alors sur les versions encore prises en charge.

Cela modifie la gestion des incidents d’une manière bien particulière : vous devez déboguer sans l’aide des développeurs en amont. Si vous rencontrez un véritable bug d’exécution, vous ne pouvez compter sur aucun correctif rétroporté, aucun triage de la part du responsable de maintenance, et les discussions au sein de la communauté concernant cette version, que peu de gens utilisent encore, se font de plus en plus rares. Les profileurs, les débogueurs et les agents APM abandonnent eux aussi les anciens environnements d’exécution ; il se peut donc que les outils auxquels vous auriez normalement recours ne puissent pas se connecter.

Préparez-vous : si vous restez sur la version 18 pour l'instant, prévoyez un délai moyen de résolution plus long pour tout ce qui concerne l'exécution, et gardez à portée de main un environnement de débogage 18.x reproductible afin de ne pas avoir à en créer un en plein milieu d'un incident.

Vos options maintenant que Node.js 18 est arrivé en fin de vie

Maintenant que Node.js 18 n'est plus pris en charge par le projet Node.js, chaque équipe doit prendre une décision. Rester sur sa position est l'une des options possibles – mais comme elle n'est généralement pas consignée par écrit, elle finit par devenir la solution par défaut.

	Ne rien faire	Passer à une version LTS prise en charge	Soutien étendu
Effort initial	Faible	Haut	Faible
Effort récurrent	Suivi, validation des risques, éléments probants d'audit	Aucun après la migration	Faible
Corrections de sécurité	Aucun	Officiel et en cours	En cours, pour les vulnérabilités concernées
Risque de sécurité	Évolue à chaque nouvelle version	Le plus bas	Réduit
Dette technique	Pousse	Validé	Continue de grandir
À déguster de préférence lorsque	Isolé et sur le point d'être mis hors service	Il y a de la capacité disponible ce trimestre	La mise à niveau est prévue dans deux trimestres ou plus

Ne rien faire

Ne rien changer est l'option la moins coûteuse ce trimestre, mais la plus coûteuse à plus long terme. Lorsqu'un système est stable et ne présente aucun dysfonctionnement, la tentation de ne pas y toucher est forte.

Ce n'est pas forcément une mauvaise décision. Un service qui est véritablement isolé, qui ne traite aucune donnée réglementée et dont la date de mise hors service, déjà financée, est prévue dans un ou deux trimestres, ne mérite peut-être pas du tout d'être migré.

Ce qui rend ce choix erroné, c'est de considérer que cela ne coûte rien. Ne rien faire vous coûte tout de même la surveillance de la vulnérabilité, la validation de l'acceptation des risques, la documentation d'audit, ainsi qu'une position plus fragile en cas de problème. Ces heures sont bien réelles, et elles reviennent régulièrement.

Point de décision : Si le service est accessible depuis Internet ou fait partie du périmètre d'audit, cette option n'est pas envisageable. S'il est isolé et que sa mise hors service est prévue, consignez formellement l'acceptation du risque et passez à des tâches plus utiles.

Mise à niveau vers une version LTS prise en charge

La mise à niveau est la seule solution qui permet de résoudre définitivement le problème, plutôt que de simplement le gérer. À compter d'août 2026, voici les options qui s'offrent à vous :

• Node.js 24 (Krypton) – Version LTS active, fin de vie le 30 avril 2028. La version par défaut pour la plupart des équipes.
• Node.js 22 (Jod) – en maintenance LTS depuis le 21 octobre 2025, fin de vie le 30 avril 2027. Uniquement des corrections de bogues critiques et des mises à jour de sécurité.
• Node.js 26 – actuellement dans la branche « Current », dont la promotion vers la branche « Active LTS » est prévue en octobre 2026, avec une fin de vie prévue le 30 avril 2029.

 

Faites attention au piège que recèle cette liste. Node.js 22 semble être le choix le plus prudent, mais il a déjà dépassé la phase « Active LTS » et il ne lui reste plus qu’un an de support ; migrer de la version 18 à la version 22 reviendrait donc à refaire la même opération avant avril 2027. À moins qu’un élément de votre arborescence de dépendances n’empêche spécifiquement le passage à la version 24, passer à la version 22 ne vaut pas la peine.

La mise à niveau rétablit la prise en charge officielle en matière de sécurité et vous ramène à un environnement d'exécution toujours pris en charge par l'écosystème au sens large. En revanche, cela ne se fera pas en un après-midi. Passer de la version 18 à la version 24 implique de franchir deux lignes LTS et plusieurs versions majeures de la série V8 : les modules natifs doivent être recompilés selon la nouvelle ABI, les builds node-gyp et les binaires précompilés doivent être vérifiés, et les builds Linux officiels nécessitent une version de glibc plus récente que celle requise par les builds Node.js 18 – ce qui suffit à exclure les anciennes distributions sans modification de l’image de base. Prévoyez un cycle de test complet en environnement de préproduction plutôt qu’une simple mise à jour de version dans l’environnement de CI.

Conseil de pro : Évitez Node.js 20. Sa fin de vie étant prévue le 30 avril 2026, passer à cette version reviendrait à faire un pas de côté vers un autre environnement d'exécution non pris en charge. Si votre migration intervient après l’entrée de Node.js 26 en mode LTS en octobre 2026, la version 26 bénéficiera de la période de support prévue la plus longue – mettez cela en balance avec l’expérience de production plus longue de la version 24 et sa prise en charge plus étendue des dépendances. Dans tous les cas, n’oubliez pas que le projet précise que ses dates prévisionnelles sont susceptibles d’être modifiées.

TuxCare, un soutien sans faille tout au long du cycle de vie

Tous les systèmes ne peuvent pas être mis à niveau dans les délais prévus par le projet. La longueur des cycles de validation, les procédures d’approbation des modifications, les piles logicielles certifiées et les applications fournies par les éditeurs repoussent tous la date de mise en service effective de plusieurs trimestres plutôt que de quelques semaines.

Avec le support à cycle de vie illimité de TuxCarede TuxCare, Node.js 18 continue de bénéficier de correctifs de sécurité pour les vulnérabilités couvertes après la fin de vie officielle. Les correctifs sont fournis sans modification du code de l’application, ce qui rend cette approche viable pour les équipes qui ne peuvent pas procéder à une nouvelle certification de leur application pour le moment. TuxCare prend en charge les versions 12, 14, 16, 18 et 20 de Node.js.

Considérez-le comme une étape intermédiaire plutôt que comme une fin en soi. Il permet de traiter l'aspect « correctifs » et « gestion des vulnérabilités » du problème. Il n'empêche pas votre arborescence de dépendances de se dégrader ni votre dette technique de s'alourdir, et la mise à niveau devra tout de même avoir lieu à terme.

Point de décision : Si vous pouvez réellement déployer la mise à niveau ce trimestre, procédez à la mise à niveau et ignorez la solution de transition. Si la date est prévue dans deux trimestres ou plus, ou si vous faites l'objet d'un audit et ne pouvez pas appliquer de correctif, optez pour la solution de transition et maintenez le financement de la migration.

Sécurisez vos charges de travail Node.js 18 avec TuxCare

Node.js 18 n'a pas changé. En revanche, son statut de prise en charge a évolué. Le même binaire qui était encore pris en charge en avril 2025 est désormais le composant le plus ancien et non pris en charge de votre application, et il accumule de nouvelles vulnérabilités non corrigées à chaque fois que le projet publie une mise à jour de sécurité.

Le problème, c'est que la solution qui semble évidente comporte une erreur. Node.js 22 est la version qui s'impose naturellement après la 18, mais c'est aussi celle qui vous fait gagner le moins de temps. Node.js 24 est la version idéale pour la plupart des équipes, mais c'est également celle qui nécessite la migration la plus complexe. C'est précisément dans cet écart entre la solution facile et la solution correcte que le support étendu trouve toute sa raison d'être.

Pour les organisations qui ne peuvent pas y parvenir immédiatement, le support à vie d'Endless pour Node.js assure la mise à jour des charges de travail Node.js 18 contre les vulnérabilités connues pendant que la migration est planifiée et testée de manière appropriée, sans nécessiter de modifications du code des applications.

Si vous utilisez encore Node.js 18, vous devez prendre une décision ce trimestre : mise à niveau, solution de transition ou acceptation des risques documentés. La seule option qui deviendra de plus en plus coûteuse à mesure que le temps passe est de ne rien faire.

Foire aux questions sur la fin de vie de Node.js 18