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
- Node.js 20 a atteint sa fin de vie le 30 avril 2026, rejoignant ainsi Node.js 18 et toutes les versions antérieures qui ne bénéficient plus d'aucun correctif de sécurité de la part du projet.
- Une version de Node.js en fin de vie (EOL) implique que les vulnérabilités CVE déjà rendues publiques ne sont pas corrigées, et qu'aucun correctif ne sera fourni pour les vulnérabilités découvertes ultérieurement.
- Chaque binaire officiel de Node.js regroupe environ 25 composants. Certains, comme OpenSSL, zlib et ICU, existent également sous forme de bibliothèques système que votre système d’exploitation met à jour ailleurs, mais jamais au sein de Node.js ; d’autres, comme V8 et undici, ne disposent d’aucun paquet système, de sorte que les correctifs en amont ne vous parviennent que via une nouvelle version de Node.js. Chaque copie intégrée est gelée à la fin de son cycle de vie (EOL).
- Vous avez le choix entre passer à une version LTS prise en charge, abandonner Node.js ou bénéficier d'un support prolongé afin de continuer à recevoir les correctifs pendant que vous planifiez la migration selon votre propre calendrier.
Si une partie de votre pile utilise encore Node.js 18 ou 20, vous n’êtes pas le seul. Les versions LTS paires sont largement utilisées en production, et elles ne cessent pas de fonctionner dès la fin de leur prise en charge. Elles ne bénéficient simplement plus de correctifs. Node.js 20 a franchi cette étape le 30 avril 2026, et toutes les versions antérieures l’avaient déjà franchie.
Cet article présente les versions de Node.js dont la fin de vie est dépassée, explique ce que cela implique pour la sécurité et la conformité des applications qui s'appuient sur ces versions, et propose trois pistes réalistes pour aller de l'avant : mettre à niveau, migrer ou recourir au support étendu de Node.js afin de continuer à recevoir des correctifs en attendant de prendre une décision.
Quelles sont les versions de Node.js arrivées en fin de vie ?
Depuis juillet 2026, seules trois branches de version bénéficient encore de mises à jour de la part du projet Node.js : la branche 26.x (actuelle), la branche 24.x (LTS active) et la branche 22.x (LTS de maintenance). Node.js 20 et toutes les versions antérieures ont atteint leur fin de vie, tout comme les branches impaires qui ne sont jamais entrées en LTS.
| Version (nom de code) | Statut | Fin de l'assistance |
| 26.x | Actuellement ; entrera en LTS en octobre 2026 | Avril 30, 2029 |
| 24.x (Krypton) | LTS active | Avril 30, 2028 |
| 22.x (Jod) | Maintenance LTS | Avril 30, 2027 |
| 25.x, 23.x, 21.x, 19.x | Fin de vie ; n'a jamais été intégré à la version LTS | Juin 2026 et avant |
| 20.x (Fer) | Fin de vie | Avril 30, 2026 |
| 18.x (Hydrogène) | Fin de vie | Avril 30, 2025 |
| 17.x et versions antérieures | Fin de vie | 2023 ou avant |
Historiquement, Node.js a toujours publié deux versions majeures par an, les versions paires bénéficiant d'un support à long terme (LTS) : environ six mois en tant que version « Current », douze mois en tant que version « Active LTS » avec des corrections de bogues et de sécurité, puis une phase de maintenance limitée aux corrections critiques – soit environ 30 mois de support LTS, ou environ 36 mois entre la première publication et la fin de vie.
Ce modèle est en train d'évoluer. À partir de Node.js 27, le projet passe à une version majeure par an, chaque version devient une version LTS, et les numéros de version s’alignent sur l’année civile : 27.0.0 en 2027, 28.0.0 en 2028. Un nouveau canal Alpha s’ouvrira en octobre 2026 pour reprendre le rôle de test précoce que jouaient auparavant les versions impaires, et Node.js 26 est la dernière version sous l’ancien modèle. La durée totale de support reste inchangée, soit environ 36 mois entre la première version « Current » et la fin de vie. Un calendrier plus prévisible, mais l’issue reste la même : chaque branche a toujours une date à partir de laquelle les correctifs cessent d’être fournis.
Vous pouvez également consulter notre analyse détaillée du calendrier de fin de vie (EOL) de Node.js 18 et de ses répercussions dans notre guide dédié.
Ce que la fin de vie de Node.js implique pour vos applications
Le projet Node.js est d'une franchise inhabituelle à ce sujet. Sa propre page consacrée à la fin de vie met en garde contre quatre conséquences : l’arrêt des correctifs de vulnérabilités, la rupture de la chaîne d’outils, la dérive de l’écosystème à mesure que les paquets populaires cessent de prendre en charge les anciens environnements d’exécution, et des problèmes de conformité car « de nombreux audits sectoriels interdisent l’utilisation d’environnements d’exécution non maintenus ».
Les vulnérabilités CVE non corrigées que vous connaissez déjà
Node.js publie régulièrement des mises à jour de sécurité, et chacune d'entre elles ignore complètement les versions arrivées en fin de vie. Au 30 juillet 2026, la page « Fin de vie » du projet répertorie 27 vulnérabilités de gravité élevée concernant Node.js 20 et 15 concernant Node.js 18, et ces chiffres ne cessent d'augmenter.
C'est ce schéma qui rend la situation dangereuse. La version de sécurité du 29 juillet 2026 ne concernait que les branches 26.x, 24.x et 22.x. Elle corrigeait onze vulnérabilités, dont trois de gravité élevée, notamment un bug de réentrance HTTP/2 dans le module nghttp2 intégré, qui exposait le processus à une utilisation après libération (use-after-free) de la mémoire heap. Node.js 20 et 18 n’ont reçu aucune correction, et l’avis de sécurité indiquait précisément aux attaquants où chercher dans chaque version n’ayant pas bénéficié du correctif. Avis public, correctif public, comparaison publique. Le gros du travail de découverte est déjà effectué.
Pour vous faire une idée de ce à quoi ressemble une faille grave, prenez l'exemple de la faille « HTTP/2 Rapid Reset » (CVE-2023-44487). Elle a été exploitée en tant que vulnérabilité « zero-day » pour lancer les plus grandes attaques DDoS jamais enregistrées à l’époque, et elle a affecté tous les serveurs Node.js sur lesquels HTTP/2 était activé. Les versions 18 et 20 de Node.js ont été corrigées en quelques jours. Si la même faille était découverte aujourd’hui, aucune de ces deux versions ne bénéficierait d’un correctif de la part du projet Node.js.
Les vulnérabilités CVE qui ne feront jamais l'objet d'un correctif
L'équipe de sécurité de Node.js n'évalue ni ne corrige les vulnérabilités des versions arrivées en fin de vie (EOL). En janvier 2025, le projet a cherché à rendre cette information visible pour les scanners de vulnérabilités en publiant CVE-2025-23087, un identifiant CVE global couvrant Node.js 17 et toutes les versions antérieures, accompagné d’identifiants CVE spécifiques pour les versions 19 et 21. Le programme CVE a rejeté ces trois identifiants. La nouvelle politique est plus large : chaque nouvel identifiant CVE de Node.js couvre désormais par défaut les versions en fin de vie, à moins que le projet ne dispose d’informations spécifiques indiquant qu’il ne s’applique pas à l’une d’entre elles.
Ainsi, les versions 18 et 20 de Node.js ne sont pas explicitement mentionnées dans un avis général de fin de vie (EOL) : elles sont présumées concernées par tous les avis qui suivront. La raison invoquée par le projet est le manque de ressources : avec plus de vingt versions en fin de vie, chacune présentant des dépendances et des processus de compilation différents, ainsi que des vulnérabilités qui se manifestent de manière variable en fonction de composants tels qu’OpenSSL, une évaluation exhaustive n’est pas réalisable. Tout ce qui y est détecté reste donc non évalué et non corrigé.
Signaux d'alerte en matière de conformité
Les auditeurs parviennent à la même conclusion par une autre voie. PCI DSS 4.x L'exigence 6.3.3 prévoit que les correctifs pour les vulnérabilités critiques, identifiées via votre propre processus de classement des risques, soient installés dans un délai d'un mois à compter de leur publication, ce qu'aucun processus ne peut garantir lorsqu'aucun correctif n'existe. Les critères de sécurité du SOC 2 supposent l'existence d'un processus de gestion des vulnérabilités, et les logiciels pour lesquels aucun correctif n’est disponible rendent cette démonstration difficile. Pour les charges de travail fédérales et réglementées, un environnement d’exécution non maintenu peut constituer un constat en soi, avant même que quiconque ne pose de questions sur des CVE spécifiques.
Le risque caché : l'arborescence des dépendances intégrées de Node.js
Voici ce qui surprend même les équipes les plus expérimentées : Node.js ne se résume pas à Node.js. La répertorie répertorie 30 composants dans son arborescence source, et environ 25 d’entre eux sont intégrés à chaque binaire officiel de Node.js. Cela inclut le moteur JavaScript V8, la boucle d’événements libuv, l’analyseur HTTP llhttp, le client HTTP undici, nghttp2, nghttp3 et ngtcp2 pour HTTP/2 et HTTP/3, le résolveur DNS c-ares, zlib, brotli et zstd pour la compression, ICU, SQLite, npm lui-même, ainsi que la propre copie d’OpenSSL de Node. (L'ensemble exact varie selon la version majeure — Node.js 18 et 20 sont antérieurs à l'intégration de SQLite et de zstd, par exemple.)
Ces composants se répartissent en deux groupes, qui posent tous deux problème après la fin de vie (EOL). Environ la moitié d’entre eux existent également sous forme de bibliothèques système : OpenSSL, zlib, SQLite, ICU, nghttp2, c-ares, libuv. Votre système d’exploitation applique des correctifs à ces bibliothèques ailleurs dans le système, mais les binaires officiels de Node.js – ceux provenant de nodejs.org, de gestionnaires de versions comme nvm et des images Docker standard – sont compilés à partir de leurs propres copies, et les mises à jour du système d’exploitation ne les atteignent jamais. (Certains paquets de distributions Linux sont liés à quelques bibliothèques système, mais il s’agit là d’une exception.) L’autre moitié, comprenant V8, llhttp, undici et npm, est maintenue en amont mais ne dispose d’aucun paquet système sur votre machine ; ainsi, un correctif apporté au projet en amont ne vous parvient que lorsqu’une nouvelle version de Node.js l’intègre. Dans les deux cas, la conclusion est la même : les correctifs vous parviennent via une nouvelle version de Node.js ou pas du tout, et lorsqu’une branche de version arrive en fin de vie (EOL), l’arborescence entière se fige.
Il ne s'agit pas d'une vulnérabilité théorique. « Rapid Reset » était une faille au niveau du protocole HTTP/2 que Node.js a corrigée via son module nghttp2 intégré, et non dans le code écrit par l'équipe de Node.js. La mise à jour de sécurité de juillet 2026 a inclus des mises à jour d'undici et de llhttp, en plus des correctifs propres à Node.js. Sur une version prise en charge, celles-ci s'installent automatiquement. Sur une version en fin de vie (EOL), chacun de ces composants accumule discrètement les CVE en amont qui s’y appliquent, sans qu’il n’y ait de moyen de distribution pour les correctifs.
Toute option de support étendu digne de ce nom doit couvrir l'ensemble de cette surface ; c'est pourquoi le programme « Endless Lifecycle Support » (ELS) de TuxCare corrige l'arborescence des dépendances intégrées, et pas seulement le cœur de Node.js.
Vos options après la fin de vie de Node.js
Il existe trois voies possibles, et celle qui vous convient le mieux dépend de votre capacité actuelle à faire face aux risques liés à la migration :
- Vous ne pouvez pas effectuer de mise à niveau ce trimestre, mais vous devez rester à jour ? Optez pour le support prolongé.
- Vous disposez du temps nécessaire pour les travaux d'ingénierie et d'une chaîne de dépendances compatible ? Passez à une version LTS prise en charge.
- Node.js ne représente qu'une petite partie de votre pile, voire une partie de plus en plus réduite ? Pourquoi ne pas en profiter pour envisager de l'abandonner ?
Bénéficiez d'un support à vie pour Node.js
Le moyen le plus rapide d'éliminer immédiatement le risque sans toucher à votre base de code consiste à appliquer les correctifs fournis par le fournisseur. Le service ELS de TuxCare pour Node.js fournit des correctifs de sécurité continus pour Node.js 12, 14, 16, 18 et 20 : les correctifs sont rétroportés depuis l’amont, testés pour vérifier leur intégrité et l’absence de régressions, signés, couverts par un SLA et distribués via les gestionnaires de paquets que vous utilisez déjà. TuxCare propose ce service en tant que partenaire du programme de pérennité de l’écosystème de l’OpenJS Foundation, et figure parmi les fournisseurs de support commercial sur la page EOL du projet Node.js lui-même.
La couverture inclut l'arborescence des dépendances groupées décrite ci-dessus, d'OpenSSL à undici, sans frais supplémentaires. Vous pouvez consulter en temps réel les vulnérabilités et les correctifs pour Node.js dans le TuxCare CVE Tracker pour voir exactement ce qui fait l'objet de correctifs.
Pour être clair sur le rôle que cela joue : il s'agit d'un tremplin, pas d'une fin en soi. ELS vous redonne ce que la fin de vie (EOL) vous enlève : le temps de planifier une mise à niveau selon vos propres conditions, plutôt que sous la pression d'une faille de sécurité ou d'un audit.
Passer à une version LTS prise en charge
La solution idéale à long terme. Node.js 24 est le fruit de plusieurs années de travail sur les performances, intègre les dernières fonctionnalités de V8 et bénéficiera d’un support jusqu’au 30 avril 2028. Node.js 22 est également toujours pris en charge, mais seulement jusqu’au 30 avril 2027, ce qui en fait davantage une étape intermédiaire qu’une solution définitive. Si votre arborescence de dépendances est saine et que votre couverture de test est satisfaisante, un saut d’une version majeure est souvent gérable.
L'effort requis augmente toutefois proportionnellement à la distance et à la complexité du code source. Chaque version majeure comporte des changements rompant la compatibilité, les extensions natives doivent être recompilées selon la nouvelle ABI, et les paquets dont la version a été figée il y a des années peuvent ne plus disposer d'une version compatible. Passer de la version 18 à la version 24 ne correspond pas à une seule migration, mais à trois migrations successives.
Passer à une autre technologie
Si un service doit de toute façon être réécrit, la fin de vie (EOL) peut être l’occasion de le consolider sur ce que votre organisation considère désormais comme stratégique, qu’il s’agisse d’un autre environnement d’exécution comme Deno ou Bun, ou d’un langage complètement différent. Cette flexibilité est bien réelle, mais son coût l’est tout autant : une migration peut impliquer de réécrire une grande partie du fonctionnement du service, avec toute la charge de tests que cela implique. Cela n’a que rarement du sens en réponse à la seule fin de vie (EOL).
Les risques liés à une mise à niveau précipitée
Une mise à niveau vers une nouvelle version majeure de Node.js est un véritable projet, et non une simple mise à jour des dépendances. Cela implique d’adapter le code aux changements d’API incompatibles, de vérifier la compatibilité de l’ensemble de votre fichier de verrouillage, de recompiler les modules natifs, de mettre à jour les images CI, les fichiers Dockerfile et les chaînes d’outils de compilation, ainsi que d’effectuer des tests de régression sur tout ce qui concerne l’environnement d’exécution.
Les équipes qui condensent ce travail dans le cadre d’une situation d’urgence, généralement parce qu’un audit ou la divulgation d’une vulnérabilité CVE les y contraint, en paient souvent le prix en aval : instabilité de la production due à des chemins de traitement insuffisamment testés, pic de la charge de support, solutions de contournement mises en place qui se transforment en dette technique, et coûts imprévus surgissant précisément là où le budget ne les avait pas anticipés. Ce schéma se répète avec une telle régularité que le simple fait d’éviter ce scénario de mise à jour forcée constitue en soi une stratégie de sécurité. La pression des délais et une ingénierie rigoureuse ne font pas bon ménage.
Assurez la sécurité de Node.js au-delà de la fin de vie (EOL) avec TuxCare
TuxCare a consacré plus d’une décennie à mettre en place la méthodologie nécessaire à la correction des vulnérabilités au niveau de l’entreprise, et fournit aujourd’hui des correctifs rétroportés à plus de 2 300 entreprises clientes dans les secteurs des services financiers, des télécommunications, de la santé et des administrations publiques. Le processus de correction associe la surveillance automatisée des vulnérabilités, l’évaluation des correctifs et le portage rétrospectif à une validation par des experts ; chaque version est construite à partir de sources vérifiées et signée, avec des attestations couvrant ses dépendances.
Pour Node.js, cela se traduit par des correctifs de sécurité continus, une stabilité garantie et des preuves d'audit pour les versions sur lesquelles vos applications tournent réellement : couverture des dépendances intégrées, correctifs fournis via vos gestionnaires de paquets existants, et un coût qui ne représente qu'une fraction de celui d'une migration imprévue. Découvrez ELS pour Node.js, ou commencez par le CVE Tracker pour consulter en temps réel les vulnérabilités et les correctifs disponibles pour Node.js.
