Application Node.js vulnérable ou cassée par une montée de version

Le 21 octobre 2026, Node.js a publié des correctifs de sécurité pour ses versions 22, 24 et 26, dont une faille de niveau élevé dans la décompression Brotli. Les versions en fin de vie, comme Node.js 20, ne sont pas corrigées. J'audite votre application, je la mets à jour, je la remets en route si la montée de version la casse, et je la sécurise.

Faire auditer mon application

Les failles récentes

Le 21 octobre 2026, le projet Node.js a publié les versions 22.23.4, 24.22.1 et 26.12.1. La faille la plus grave, CVE-2026-111497 (niveau élevé), touche le décodeur Brotli intégré à Node.js : des données compressées malformées, décompressées avec node:zlib, peuvent corrompre la mémoire du processus et mener à un plantage, à une fuite de mémoire ou à une exécution de code à distance. Le CERT Santé précise que fetch() appelle aussi ce décodeur sur une réponse compressée en Brotli.

Le projet Node.js le rappelle à chaque publication de sécurité : les versions en fin de vie sont toujours concernées et ne reçoivent pas de correctif. Node.js 20 est en fin de vie depuis le 30 avril 2026. Node.js 22 est maintenu jusqu'au 30 avril 2027, Node.js 24 jusqu'au 30 avril 2028, et Node.js 26 doit passer en LTS le 28 octobre 2026 selon le calendrier officiel.

L'autre risque vient des dépendances npm. En septembre 2025, l'agence américaine CISA a alerté sur le ver « Shai-Hulud », qui avait compromis plus de 500 paquets npm pour voler des identifiants. En 2026, la campagne « Mini Shai-Hulud » a continué, par exemple avec une version piégée d'intercom-client le 30 avril 2026 et de tensorlake le 8 octobre 2026, qui volaient les identifiants de la machine pendant l'installation.

La méthode pour suivre ces correctifs est dans patcher ses runtimes quand on est une PME. Pour un site PHP, voir aussi WordPress en erreur critique après la mise à jour PHP.

Les messages d'erreur après une montée de version

Mettre à jour Node.js corrige les failles, mais peut casser une application qui n'a pas suivi. Voici les messages les plus fréquents, tels que Node.js, npm et Yarn les affichent (en anglais uniquement). Les parties variables (chemins, noms de modules, numéros de version) sont remplacées par « … ».

Module ES chargé avec require() (ERR_REQUIRE_ESM)

Error [ERR_REQUIRE_ESM]: require() of ES Module … from … not supported.

Ce que ça veut dire : Du code CommonJS charge avec require() une dépendance publiée uniquement en module ES. Cela arrive souvent après la mise à jour d'une dépendance. Depuis Node.js 20.19, 22.12 et 23, require() sait charger la plupart des modules ES et ce code d'erreur est déprécié ; si le module utilise un await au niveau supérieur, Node.js renvoie alors ERR_REQUIRE_ASYNC_MODULE.

Ce que je fais : J'identifie la dépendance en cause, puis je passe à une version de Node.js qui sait la charger, je la remplace par import() ou je fige une version compatible.

Module introuvable (MODULE_NOT_FOUND)

Error: Cannot find module '…'

Ce que ça veut dire : Le chargeur de modules de Node.js ne trouve pas le fichier ou le paquet demandé : dépendances non réinstallées après la montée de version, chemin erroné, ou paquet qui a changé ses points d'entrée.

Ce que je fais : Je vérifie l'installation des dépendances et les points d'entrée déclarés, puis je corrige l'import ou la version du paquet.

Module natif compilé pour une autre version de Node.js

The module '…' was compiled against a different Node.js version using NODE_MODULE_VERSION … This version of Node.js requires NODE_MODULE_VERSION … Please try re-compiling or re-installing the module (for instance, using `npm rebuild` or `npm install`).

Ce que ça veut dire : Un module natif (du code C ou C++ compilé, par exemple pour une base de données ou du traitement d'images) a été construit pour une autre version de Node.js. Chaque version majeure a son propre numéro NODE_MODULE_VERSION.

Ce que je fais : Je recompile les modules natifs pour la nouvelle version, ou je passe à une version du paquet compatible, et je refais l'image ou le déploiement proprement.

Algorithme refusé par OpenSSL 3 (ERR_OSSL_EVP_UNSUPPORTED)

error:0308010C:digital envelope routines::unsupported

Ce que ça veut dire : Depuis Node.js 17, Node.js embarque OpenSSL 3, qui refuse par défaut d'anciens algorithmes ou tailles de clé. Les vieux outils de build front (anciennes versions de webpack, par exemple) déclenchent souvent cette erreur. L'option --openssl-legacy-provider n'est qu'un contournement temporaire.

Ce que je fais : Je mets à jour l'outil qui utilise l'algorithme refusé plutôt que de laisser l'option de contournement en place.

Avertissement de dépréciation (DEP0005)

[DEP0005] DeprecationWarning: Buffer() is deprecated due to security and usability issues. Please use the Buffer.alloc(), Buffer.allocUnsafe(), or Buffer.from() methods instead.

Ce que ça veut dire : Pas une panne : Node.js signale une API dépréciée, ici le constructeur Buffer(). Chaque dépréciation a un code DEP suivi de quatre chiffres, documenté par Node.js ; certaines finissent par être supprimées dans une version majeure suivante.

Ce que je fais : Je relève les avertissements DEP du journal, je remplace les API concernées et je vérifie celles qui disparaissent dans la version cible.

Version de Node.js refusée par un paquet

yarnThe engine "node" is incompatible with this module. Expected version … Got …

npmUnsupported engine

Ce que ça veut dire : Le champ engines du package.json d'une dépendance, ou de votre projet, n'accepte pas la version de Node.js installée. Yarn 1 bloque l'installation ; npm signale le code EBADENGINE sous forme d'avertissement, et bloque si l'option engine-strict est activée.

Ce que je fais : J'aligne la version de Node.js sur ce que demandent les dépendances, ou je mets à jour les dépendances qui exigent une version dépassée.

Fichier de verrouillage désynchronisé (npm ci)

`npm ci` can only install packages when your package.json and package-lock.json are in sync. Please update your lock file with `npm install` before continuing.

The `npm ci` command can only install with an existing package-lock.json with lockfileVersion >= 1.

Ce que ça veut dire : npm ci, utilisé en intégration continue et en déploiement, installe exactement ce que décrit le fichier package-lock.json. Il refuse si ce fichier manque ou ne correspond plus au package.json.

Ce que je fais : Je régénère le fichier de verrouillage de façon contrôlée, je relis les versions qui changent, et je le versionne avec le projet.

Pourquoi l'application casse ou reste exposée

Le code n'a souvent pas changé : c'est Node.js, ses dépendances ou l'hébergement qui ont bougé.

Une version de Node.js en fin de vie
Node.js 20 et les versions plus anciennes ne reçoivent plus de correctif de sécurité, y compris pour la faille Brotli du 21 octobre 2026.
Des dépendances qui ont changé
Paquets passés aux modules ES, modules natifs à recompiler, champ engines plus strict : une montée de version de Node.js réveille ces écarts.
OpenSSL 3 et l'environnement
Depuis Node.js 17, OpenSSL 3 refuse par défaut d'anciens algorithmes. Les images Docker et l'hébergement doivent aussi suivre la bonne version.
La chaîne d'approvisionnement npm
Un paquet piégé exécute son code dès l'installation. Le fichier de verrouillage, npm ci et la rotation des identifiants exposés limitent les dégâts.

Ce que je propose

Avant de toucher à l'application, je fais l'inventaire des versions de Node.js utilisées (serveurs, images Docker, intégration continue) et je travaille sur une branche ou une copie quand c'est possible.

  1. Audit de sécurité

    Versions de Node.js en production, failles connues des dépendances (npm audit et avis de sécurité), recherche de versions piégées dans les fichiers de verrouillage, revue des scripts d'installation, des jetons npm et des secrets d'intégration continue.

    Livrable : Un rapport priorisé des risques et des correctifs.

  2. Mise à niveau et remise en route

    Passage à une version de Node.js maintenue, correction des erreurs de modules ES, de modules natifs, d'OpenSSL 3 et de dépendances, remplacement des API dépréciées, mise à jour des images Docker et de l'intégration continue.

    Livrable : Une application qui tourne sur une version de Node.js corrigée.

  3. Suivi dans la durée

    Veille sur les publications de sécurité de Node.js et les avis npm, mises à jour encadrées, calendrier de migration avant chaque fin de vie.

    Livrable : Une application qui suit les correctifs au lieu de les subir.

Vos questions sur la mise à jour de Node.js

Quelle version de Node.js installer pour corriger la faille Brotli ?

Au minimum 22.23.4, 24.22.1 ou 26.12.1, selon votre branche. Si vous êtes en Node.js 20 ou plus ancien, il n'y a pas de correctif : il faut migrer vers une branche maintenue.

Mon application n'utilise pas Brotli, est-elle concernée ?

Peut-être : une bibliothèque, ou fetch() sur une réponse compressée en Brotli, peut appeler le décodeur sans que votre code le fasse directement. La même publication corrige aussi d'autres failles. Le plus sûr est de mettre à jour.

Puis-je garder --openssl-legacy-provider ?

La note de version de Node.js 17 le présente comme un contournement temporaire. Mieux vaut mettre à jour l'outil qui utilise l'ancien algorithme.

Comment savoir si une dépendance piégée a été installée ?

En comparant les versions de vos fichiers de verrouillage aux avis de sécurité publiés, et en relisant les journaux d'installation de l'intégration continue. Si une version piégée a été installée, les avis recommandent de changer tous les identifiants présents sur la machine concernée.

Les avertissements DeprecationWarning sont-ils graves ?

Ce ne sont pas des pannes, mais ils signalent du code qui peut cesser de fonctionner dans une prochaine version majeure. C'est le bon moment pour les traiter.

Votre application Node.js tourne sur une version vulnérable ou ne démarre plus ?

Envoyez-moi la version de Node.js utilisée et le message que vous voyez, je vous dis par où commencer.

Échanger avec Kamel Laïmène

Faits et libellés vérifiés le 26 octobre 2026 dans les publications de sécurité et le calendrier officiel de Node.js, le code source et la documentation de Node.js, de npm, de Yarn et d'OpenSSL, les avis du GitHub Advisory Database, l'alerte de la CISA et le CERT Santé. Cette page ne décrit pas de missions clients.

<<<<<<< HEAD ======= >>>>>>> origin/main