Node.js : randomUUID() répété dans les snapshots, permissions contournées

La version de sécurité Node.js d'octobre 2026 fait surtout parler d'elle pour ses failles de gravité élevée. Deux correctifs plus modestes méritent pourtant qu'on s'y arrête, parce qu'ils corrigent des suppositions qu'on fait sans y penser : que crypto.randomUUID() donne une valeur différente à chaque processus, et que le modèle de permissions est un mur. Pour la plupart des applications, ni l'un ni l'autre ne change quoi que ce soit. Pour deux profils bien précis, si.

Quand « aléatoire » donne la même chose dans chaque processus

La CVE-2026-106074, de gravité moyenne et corrigée sur les branches 26, 24 et 22, concerne les snapshots de démarrage et les exécutables uniques (SEA). Les caches d'entropie utilisés par crypto.randomUUID() et randomInt() étaient enregistrés dans les snapshots utilisateur et les SEA : chaque processus lancé depuis le même snapshot ou le même exécutable répétait donc les mêmes valeurs.

Pour le contexte général : un snapshot ou un SEA est une image de l'application dont l'état est capturé une fois, puis restauré dans de nombreux processus. C'est ce qui le rend rapide au démarrage. Cela veut aussi dire que tout ce qui était aléatoire au moment de la capture est partagé par toutes les copies. Ici, c'est le runtime lui-même qui avait mis de l'aléa en cache au mauvais moment, et le correctif se trouve dans le runtime.

Qui est concerné : ceux qui construisent un snapshot de démarrage utilisateur ou livrent un SEA, et y génèrent des identifiants, des jetons ou des clés avec ces fonctions. Qui ne l'est pas : une application classique lancée avec node server.js, ce qui est le cas de la plupart des applications Node.

La leçon dure plus longtemps que le correctif, en règle générale : ne dérivez jamais d'identifiants, de jetons ou de secrets à partir de valeurs créées au build. Créez-les après le démarrage du processus. Si vous livrez un SEA ou un snapshot, un test rapide consiste à afficher une valeur au démarrage, lancer l'exécutable deux fois et comparer :

// run at startup, start the executable twice, compare the output
console.log('boot id', crypto.randomUUID());

Deux lignes différentes : chaque processus a son propre aléa. Deux lignes identiques : votre runtime n'est pas corrigé, ou quelque chose est capturé trop tôt.

Le modèle de permissions est une couche, pas le mur

Le modèle de permissions de Node.js permet à un processus de restreindre son propre accès au système de fichiers, au réseau et à des ressources du même genre. Cette version y corrige deux contournements, tous deux de gravité faible : la CVE-2026-106073, un contournement via fs.realpathSync sur les branches 26, 24 et 22, et la CVE-2026-106071, un accès au système de fichiers trop large via une recherche radix avec joker, sur la 26 uniquement. Un troisième correctif faible, la CVE-2026-106070, sur la 26 uniquement, empêche ZipFile de renvoyer des octets de préfixe contrôlés par l'attaquant après l'échec de la vérification d'un en-tête ZIP.

Faible veut dire faible ici, et je ne vais pas en rajouter. C'est tout de même un rappel utile, au sens général : une restriction à l'intérieur du runtime n'est qu'une couche de défense. Si vous vous en servez pour exécuter du code auquel vous ne faites pas confiance, la vraie frontière doit se trouver en dehors de Node, au niveau du système d'exploitation : un conteneur, un utilisateur dédié sans privilèges, des montages en lecture seule.

Qui est concerné : ceux qui comptent sur le modèle de permissions pour contenir du code non fiable. Qui ne l'est pas : les applications qui ne l'ont jamais activé, et celles qui l'utilisent comme garde supplémentaire par-dessus une isolation au niveau du système.

La suite, c'est la même mise à jour que pour le reste de la version : 26.12.1, 24.22.1 ou 22.23.4 selon votre branche. Si vous livrez un SEA ou un snapshot, refaites le test des deux démarrages après la mise à jour. Source : nodejs.org, Wednesday, October 21, 2026 Security Releases.