Toujours sous Node.js 20 ? La mise à jour de sécurité du 11 novembre ne vous protégera pas

Node.js 20 ne recevra aucun correctif le 11 novembre 2026. Les mises à jour de sécurité concernent uniquement les branches 26.x, 24.x et 22.x, car Node.js 20 a atteint sa fin de vie (End-of-Life) le 30 avril 2026. Votre dernier correctif remonte à la version 20.20.2, publiée le 24 mars. Depuis, 33 CVE ont été publiées sans qu'aucune version 20.x ne soit produite. Passez à la version 24 ou 26 dès cette semaine.

Essayez Apidog dès aujourd'hui

Ces CVE sont apparues au cours de trois vagues de correctifs de sécurité qui ont laissé la branche 20 de côté. La quatrième arrive dans quelques jours, et le pré-avis qualifie sa vulnérabilité la plus critique d'ÉLEVÉE (HIGH) sur toutes les branches maintenues.

Ce qui se passe le 11 novembre et pourquoi Node.js 20 est laissé de côté

Le projet Node.js publiera de nouvelles versions 26.x, 24.x et 22.x le mercredi 11 novembre 2026 ou peu après. Aucun détail sur les CVE n'est encore public, et ces informations resteront confidentielles jusqu'à la mise à disposition des correctifs. Notre guide préparatoire pour la mise à jour de novembre détaille l'inventaire des environnements d'exécution et les commandes à exécuter le jour J ; nous ne les répéterons donc pas ici.

Node.js 20 ne figure pas sur la liste car le projet a cessé de le maintenir. La page consacrée à la fin de vie est sans équivoque : lorsque de nouvelles publications de sécurité corrigent des failles, « même si la même vulnérabilité affecte des branches en fin de vie, aucune nouvelle version ne sera publiée pour celles-ci ».

L'avis de sécurité ajoute une précision capitale : « Les versions en fin de vie sont systématiquement affectées lors de la publication d'un correctif de sécurité. »

Ce que Node.js 20 a déjà manqué

Trois vagues de correctifs de sécurité ont été publiées depuis que Node.js 20 a atteint sa fin de vie. Aucune d'entre elles ne propose de version 20.x.

Le code touché par ces correctifs est précisément celui qu'un serveur d'API exécute en permanence :

• Vérification des noms d'hôte TLS. Les mises à jour de juin et d'octobre ont toutes deux corrigé des failles permettant de faire accepter un certificat pour un mauvais hôte.
• HTTP/2. Les correctifs de sévérité élevée de juillet comprennent un use-after-free sur le tas (heap) et une vulnérabilité d'épuisement de mémoire à distance.
• DNS. Le correctif d'octobre a résolu un problème où dns.resolve*() tronquait les noms d'hôte au niveau d'un octet NUL, ce qui pouvait tromper une liste d'autorisation (allowlist).
• Compression. Le correctif d'octobre a corrigé une écriture hors limites dans le décodeur Brotli pouvant aboutir à une exécution de code à distance. Nous l'analysons en détail dans l'analyse de la RCE Brotli.

Lisez attentivement cette liste. L'équipe du projet n'évalue pas les branches en fin de vie, de sorte que ses avis ne mentionnent que les versions maintenues. Certains de ces bugs se trouvent dans du code qui n'est peut-être pas présent dans Node.js 20 : l'une des CVE d'octobre est une régression circonscrite uniquement aux versions 26.x et 24.x. Le véritable statut de chaque CVE pour Node.js 20 est donc : non corrigée et non évaluée. Personne ne vous a garanti que vous étiez à l'abri, et personne ne vérifiera.

L'enchaînement de failles (bug chaining) aggrave encore la situation. Le correctif DNS d'octobre vient compléter celui de juin, et un correctif de juillet en complète un autre de juin. Chaque nouveau patch s'appuie sur un correctif que vous n'avez pas.

« Mais ça fonctionne toujours »

C'est vrai. Et c'est bien là le problème.

Un environnement d'exécution en fin de vie ne cesse pas brutalement de fonctionner. La commande node -v affiche toujours la même version, vos tests passent et vos tableaux de bord restent au vert. Le risque apparaît là où vous ne regardez pas :

• Le correctif sert de feuille de route aux attaquants. Les correctifs, les avis de sécurité et les commits sont rendus publics en même temps ; n'importe qui peut donc analyser exactement ce qui a changé sur une branche maintenue et vérifier si le même code est présent dans Node.js 20.
• Votre plateforme continue parfois de le déployer. AWS Lambda a marqué nodejs20.x comme obsolète le 30 avril 2026, mais ne bloquera la création de nouvelles fonctions qu'à partir du 29 juillet 2027, et les mises à jour qu'au 31 août 2027.
• L'écosystème de paquets et les audits avancent sans vous. Le projet Node.js avertit que les paquets populaires abandonnent progressivement le support des versions en fin de vie, et de nombreux audits de conformité interdisent formellement l'utilisation d'environnements non maintenus.

Choisissez votre cible : Node.js 24 ou 26, mais pas 22

Migrez vers la version 24 cette semaine si vous cherchez la transition la plus rapide. Choisissez la version 26 si vous pouvez absorber davantage de suppressions d'API dès maintenant et souhaitez maximiser la durée de tranquillité. Laissez la version 22 de côté : bien qu'elle bénéficie du correctif de novembre, sa fin de vie est fixée au 30 avril 2027, soit dans moins de six mois. Vous seriez donc contraint de recommencer cette migration dès le printemps prochain.

Ces dates sont issues du calendrier des versions de Node.js. Vérifiez votre plateforme avant de vous engager. Sur AWS Lambda, par exemple, le runtime Node.js 26 est en préversion publique (public preview) et n'est pas couvert par le SLA Lambda ; la version 24 y constitue donc aujourd'hui la cible la plus sûre en production.

Étapes de migration et changements majeurs

Tous les éléments de ce tableau proviennent des notes de publication officielles de 22.0.0, 24.0.0, 25.0.0 et 26.0.0, ainsi que du guide de migration de la v22 vers la v24. Il s'agit d'une sélection ciblée pour les services d'API, et non du journal des modifications complet.

La ligne concernant OpenSSL est celle qui pose problème le plus insidieusement. Votre code ne change pas, mais la négociation TLS (handshake) avec un ancien système partenaire échoue au moment de l'exécution.

Sur une branche dédiée, mettez à jour votre fichier .nvmrc, le champ engines, votre Dockerfile et votre CI vers la version ciblée (pour une machine vierge, consultez le guide d'installation de Node.js). Réinstallez ensuite les dépendances pour recompiler les modules natifs, recherchez les API supprimées, exécutez les codemods officiels et démarrez le service en activant le suivi des avertissements d'obsolescence :

nvm install 24 && nvm use 24
rm -rf node_modules && npm ci

grep -rnE "assert \{ *type|createCipher\(|createDecipher\(|url\.parse\(|fs\.[FRWX]_OK|SlowBuffer|createSecurePair|_stream_[a-z]+|module\.register\(" \
  --include="*.js" --include="*.mjs" --include="*.ts" --exclude-dir=node_modules .

npx codemod run @nodejs/import-assertions-to-attributes
npx codemod run @nodejs/crypto-createcipheriv-migration
npx codemod run @nodejs/tls-create-secure-pair-to-tls-socket
npx codemod run @nodejs/fs-access-mode-constants

NODE_OPTIONS="--trace-deprecation" npm start

Vérifiez manuellement le résultat des codemods. Celui relatif à createCipher est formel : le code généré ne peut pas déchiffrer les données chiffrées avec l'ancienne API. Prévoyez donc une migration de données si vous êtes concerné.

Le site de Node.js ne propose pas encore de guide de migration de la v24 vers la v26 ; référez-vous donc aux notes de version 25.0.0 et 26.0.0 pour cette étape.

Vérifier que l'API se comporte à l'identique sur la nouvelle version

Les tests unitaires ne révèlent pas l'impact d'une nouvelle pile TLS ou d'un nouveau client HTTP sur le trafic réel. Pour un saut de deux ou trois versions majeures, une comparaison avant/après du service en fonctionnement s'impose, et c'est une tâche idéale pour votre agent de développement IA.

Apidog CLI permet à Claude Code, Codex ou Cursor d'exécuter vos suites de tests Apidog directement depuis le terminal. Configurez-le une bonne fois pour toutes :

npm install -g apidog-cli@latest
apidog login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Donnez ensuite cette consigne à votre agent :

My service runs on Node.js 20 in staging. Run Apidog test suite <suiteId> in project
<projectId> against environment <envId> and save reports to reports/node20. When I
redeploy on Node.js 24, run the same suite into reports/node24. List every request
whose status, body, or TLS behavior changed. Then read the service logs for deprecation
warnings and check each failure against the 22, 24, and 25 release notes: removed APIs,
changed defaults, stricter fetch and AbortSignal handling, OpenSSL key size rejections.

L'agent exécute la même suite de tests de part et d'autre de la migration :

apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
  -r cli,junit --out-dir reports/node20

# redeploy the service on the target line, restart it

apidog run --test-suite <suiteId> --project <projectId> -e <envId> \
  -r cli,junit --out-dir reports/node24

Deux règles sont indispensables pour que la comparaison reste fiable :

• Ne passez jamais l'option -k. Ce paramètre désactive la validation SSL, ce qui masque précisément les erreurs TLS que vous cherchez à identifier.
• Intégrez les appels que votre service effectue vers des tiers. Un rejet par OpenSSL se manifestera par une erreur API sur un endpoint dépendant d'un ancien système partenaire ; testez donc ces parcours, et pas seulement l'endpoint /health.

Une fois la migration validée, conservez cette étape dans votre pipeline. Le guide CI/CD pour Apidog CLI présente le workflow, et le tutoriel Claude Code détaille la configuration de l'agent.

Si vous ne pouvez pas migrer cette semaine

Achetez des versions corrigées auprès d'un tiers. La page consacrée à la fin de vie de Node.js liste trois partenaires via le programme OpenJS Ecosystem Sustainability. HeroDevs propose une offre « Never-Ending Support » avec des correctifs de sécurité. Le service « Endless Lifecycle Support » de TuxCare rétroporte les correctifs sur les versions en fin de vie. NodeSource offre des évaluations de migration et du support. L'équipe du projet qualifie cela de solution temporaire, et c'est effectivement le cas.

Réduisez la surface d'exposition atteignant le processus. Ces mesures limitent l'exposition aux catégories de failles mentionnées ci-dessus, mais ne corrigent rien :

• Terminez les connexions TLS et HTTP/2 sur un proxy ou un répartiteur de charge (load balancer) maintenu, et communiquez en simple HTTP/1.1 vers Node.js sur un réseau privé.
• Cessez de décompresser les flux Brotli provenant de sources non fiables, tant pour les requêtes entrantes que pour les contenus récupérés en externe.
• Rejetez les noms d'hôte comportant des octets NUL ou des formats d'adresse IP non canoniques avant toute vérification de liste d'autorisation ou appel sortant.
• Isolez le service : appliquez le principe du moindre privilège pour les identifiants, restreignez le trafic sortant et ne partagez aucun secret avec des services déjà mis à jour.

Documentez le risque formellement. Désignez un responsable, fixez une date butoir de migration et définissez les mesures compensatoires afin que le qualificatif « temporaire » ait une fin bien réelle.

FAQ

Node.js 20 est-il toujours pris en charge ? Non. Il a atteint sa fin de vie le 30 avril 2026. La dernière version produite est la 20.20.2 du 24 mars 2026, et le projet n'en publiera aucune autre.

Node.js 20 est-il vulnérable aux failles du 11 novembre ? Aucun détail sur les CVE n'est encore public, nul ne peut donc affirmer avec certitude lesquelles s'appliquent. L'avis indique que les versions en fin de vie sont systématiquement affectées lors d'une mise à jour de sécurité, et le projet ne les évalue pas individuellement.

Dois-je plutôt migrer vers Node.js 22 ? Non. Bien qu'il s'agisse de la transition la plus courte, son support prend fin le 30 avril 2027. Passer à la version 24 vous offre un an de support supplémentaire, et la version 26 deux ans.

Node.js 24 ou 26 ? Choisissez la version 24 si vous devez migrer dès cette semaine ou si votre plateforme ne prend pas encore pleinement en charge la 26. Optez pour la version 26 si vous pouvez tout tester à nouveau dès maintenant, car son support court jusqu'au 30 avril 2029.

J'utilise Node.js 25. Suis-je concerné ? Oui. Node.js 25 a atteint sa fin de vie le 1er juin 2026, sa dernière version étant la 25.9.0. Il ne recevra aucun correctif en novembre non plus, et la version 26 ne se trouve qu'à une version majeure d'écart.