Le projet Node.js a publié le mercredi 21 octobre 2026 une série de correctifs de sécurité. Ils concernent les trois branches encore maintenues : v26.12.1, v24.22.1 et v22.23.4. Le bulletin officiel liste dix vulnérabilités : quatre de sévérité haute, trois moyennes et trois faibles. L’une d’elles permet une exécution de code à distance. Si vous avez un serveur, une image Docker ou une CI qui tourne sous Node, la mise à jour est à faire dans la semaine.
Plan de l'article
La faille la plus grave : le décodeur Brotli #
La faille la plus sérieuse porte l’identifiant CVE-2026-111497. Selon le bulletin, le décodeur Brotli de Node.js peut écrire hors des limites de sa mémoire tampon, ce qui « permet une exécution de code à distance ». Les trois branches 22, 24 et 26 sont touchées.
Brotli est l’algorithme de compression que les navigateurs et les CDN utilisent en plus de gzip. Dans Node, on le décompresse avec zlib.createBrotliDecompress(), ou indirectement avec un client HTTP qui accepte l’en-tête Content-Encoding: br. Une application qui décompresse des données venues de l’extérieur, qu’il s’agisse d’une réponse d’API tierce, d’un fichier envoyé par un utilisateur ou d’un webhook, est donc directement exposée. Le bulletin ne donne pas de détails d’exploitation. Raison de plus pour ne pas attendre qu’ils circulent.
À lire CLI OVHcloud piégé sur GitHub : qui est concerné et quels secrets changer
Trois contournements de la vérification TLS #
Trois autres failles de sévérité haute visent la résolution de noms et la vérification des certificats :
CVE-2026-105483 : la vérification du nom d’hôte d’un certificat peut être contournée quand l’adresse IP est écrite avec des chiffres « pleine chasse », ces variantes Unicode larges des chiffres 0 à 9. Seules les branches 24 et 26 sont concernées.
CVE-2026-106069 : même type de contournement quand le nom d’hôte se résout « approximativement » en adresse IP. Les trois branches sont touchées.
CVE-2026-105482 : dns.resolve tronque les noms qui contiennent un caractère NUL. Un nom forgé peut alors être résolu comme un autre, ce qui ouvre la porte aux contournements de listes blanches de domaines.
À lire Deno rejoint Cloudflare : ce que l’arrêt du runtime change pour vos projets
Une quatrième faille de sévérité moyenne, CVE-2026-106072, va dans le même sens : avec des noms d’hôte IPv4 non canoniques, un certificat émis pour un nom DNS peut servir à authentifier une adresse IP. Si votre code fait des appels sortants vers des URL fournies par l’utilisateur, par exemple un aperçu de lien, un import par URL ou un webhook configurable, ces quatre failles touchent exactement vos protections anti-SSRF.
Le cas piégeux de randomUUID dans les snapshots #
Parmi les failles moyennes, CVE-2026-106074 mérite qu’on s’y arrête. Les caches d’entropie de crypto.randomUUID() et crypto.randomInt() étaient sauvegardés dans les « startup snapshots » et dans les exécutables autonomes (SEA). Conséquence : chaque processus lancé à partir du même snapshot génère les mêmes valeurs. Si vous empaquetez une application en SEA ou si vous utilisez --build-snapshot pour accélérer le démarrage, vos identifiants « aléatoires » ne l’étaient plus d’un processus à l’autre. Il faut mettre à jour, puis régénérer le snapshot ou l’exécutable.
La dernière faille moyenne, CVE-2026-105481, touche les sockets keep-alive : un client pouvait traiter une réponse écrite avant même l’envoi de sa requête.
Le Permission Model aussi
Deux des failles faibles concernent le Permission Model (--permission). L’une permet de le contourner via fs.realpathSync (CVE-2026-106073) sur les trois branches. L’autre accorde des droits trop larges sur le système de fichiers avec les jokers (CVE-2026-106071), sur la branche 26 seulement. La troisième faille faible, propre à Node 26, touche la lecture de fichiers ZIP (CVE-2026-106070). Si vous comptez sur ce modèle pour isoler du code tiers, ce bulletin rappelle qu’il reste une couche de défense en profondeur, pas une sandbox.
À lire Windows 10 : non, l’ESU ne s’arrête pas ce 13 octobre 2026 — vous êtes couverts jusqu’en 2027
Les dépendances embarquées #
Les versions publiées embarquent aussi des mises à jour de c-ares, de Undici et du magasin de certificats racines (suite à la compromission d’une autorité intermédiaire eMudhra), ainsi qu’OpenSSL pour les branches 22 et 24 et SQLite pour la branche 22. Si vous figez la version de Node dans vos images, ces correctifs n’arrivent qu’en changeant de version.
Quelle version viser, et quand #
Concrètement :
Branche 26 : passez en 26.12.1. C’est aussi la branche qui deviendra LTS le 28 octobre selon le calendrier du groupe de travail Release.
Branche 24 : passez en 24.22.1. La branche « Krypton » est passée en maintenance le 20 octobre, avec une fin de support prévue le 30 avril 2028.
À lire Installer Git : Guide Complet 2026 – Tutoriel
Branche 22 : passez en 22.23.4. Elle est en maintenance jusqu’au 30 avril 2027, il est temps de planifier la migration.
Le bulletin le rappelle : les versions arrivées en fin de vie (Node 20 et antérieures) sont toujours concernées quand une version de sécurité sort, et elles ne reçoivent plus de correctif. Le projet renvoie vers sa page sur la fin de vie pour les options de support commercial.
Côté pratique : mettez à jour les tags de vos images de base (node:24-alpine et consorts), relancez vos pipelines pour qu’ils n’utilisent pas une image en cache, et vérifiez avec node -v en production plutôt que dans votre Dockerfile. Sur un serveur géré par nvm ou par le gestionnaire de paquets de la distribution, c’est la version réellement lancée par le gestionnaire de processus (pm2, systemd) qui compte.
