Node.js : pourquoi deux processus pouvaient générer les mêmes UUID

Avis Node.js du 21 octobre 2026. CVE-2026-106074 concerne les applications qui fabriquent une image de démarrage, ou snapshot, après avoir utilisé crypto.randomUUID(), crypto.randomUUIDv7() ou crypto.randomInt(). Le projet Node.js explique que leurs caches internes d’aléa pouvaient être sérialisés dans le snapshot. Chaque processus démarré depuis cette même image retrouvait alors les mêmes octets de cache et pouvait produire les mêmes premières valeurs. Un générateur cryptographique correct au quotidien devient incorrect si son état aléatoire est cloné après initialisation.

Le mécanisme du cache cloné

Pour éviter de solliciter la source d’aléa à chaque appel, une bibliothèque peut obtenir un bloc d’octets et le consommer progressivement. Tant que chaque processus reçoit un bloc indépendant, les valeurs restent imprévisibles et les collisions extrêmement improbables. Un snapshot inverse la relation : il capture l’état du processus après que le bloc a été rempli, puis réplique cet état dans tous les processus dérivés. Leurs premiers appels consomment la même suite d’octets, dans le même ordre.

Node.js chiffre la fenêtre potentielle à 127 UUID et environ 1 000 valeurs randomInt() avant remplissage du cache. Ce ne sont pas 127 identifiants systématiquement répétés dans toute application. La faille exige qu’une fonction concernée, ou une API qui l’utilise comme URL.createObjectURL(), soit appelée pendant la construction du snapshot et que les processus descendants utilisent ensuite ce cache. Sans cette séquence, la simple utilisation de randomUUID() n’établit pas l’exposition.

Pourquoi l’impact dépend de l’usage

Un UUID de corrélation répété peut mélanger des traces ou provoquer une collision en base. Un identifiant de ressource public peut permettre de deviner un autre identifiant si deux processus exposent la même séquence. Un jeton de sécurité construit à partir d’un aléa ainsi dupliqué pourrait être plus grave, mais l’avis ne dit pas que tous les tokens Node.js sont concernés. Il faut suivre les valeurs réellement produites par ces API et la fonction de sécurité qu’elles remplissent. « UUID répété » et « authentification contournée » ne sont pas synonymes.

Un test autorisé construit un snapshot qui effectue au moins un appel concerné pendant la construction, lance deux processus indépendants depuis cette image et compare leurs premières sorties. Le contrôle négatif compare le même programme après correction ou sans appel pendant le build du snapshot. La preuve utile inclut la manière de construire l’image et le nombre d’appels, car le même code lancé sans snapshot peut se comporter normalement.

Corriger et mesurer

Node.js annonce les versions 22.23.4, 24.22.1 et 26.12.1. Les équipes doivent repérer --build-snapshot et les applications autonomes qui activent useSnapshot, reconstruire leurs artefacts avec le runtime corrigé, puis examiner si des identifiants déjà émis ont une fonction d’autorisation ou seulement de corrélation. Une mise à jour du binaire d’exécution sans reconstruction d’une image figée demande un contrôle attentif ; l’objectif est de s’assurer que l’état cloné n’est plus réutilisé.

Cette faille illustre une propriété fondamentale de la cryptographie appliquée : la qualité des octets aléatoires ne suffit pas si l’état qui les distribue est dupliqué. Les snapshots gagnent du temps au démarrage, mais ils doivent réinitialiser toute ressource censée être unique à chaque processus.

Source principale : publication de sécurité Node.js du 21 octobre 2026.