Node.js: randomUUID() repetido en snapshots y límites de los permisos

En la versión de seguridad de Node.js de octubre de 2026, casi toda la atención se la llevan los fallos de gravedad alta. Aun así, dos de las correcciones pequeñas merecen un vistazo aparte, porque corrigen suposiciones que hacemos sin pensarlo: que crypto.randomUUID() da un valor distinto a cada proceso, y que el modelo de permisos es un muro. Para la mayoría de las aplicaciones ninguna de las dos cambia nada. Para dos grupos concretos, sí.

Cuando lo «aleatorio» es igual en cada proceso

CVE-2026-106074, de gravedad media y corregida en las ramas 26, 24 y 22, tiene que ver con los snapshots de arranque y las aplicaciones de ejecutable único (SEA). Las cachés de entropía que usan crypto.randomUUID() y randomInt() se guardaban dentro de los snapshots de usuario y de los SEA, así que cada proceso arrancado desde el mismo snapshot o ejecutable repetía los mismos valores.

Como contexto general: un snapshot o un SEA es una imagen de la aplicación cuyo estado se captura una vez y luego se restaura en muchos procesos. Por eso arranca rápido. Pero también significa que cualquier valor aleatorio que existía en el momento de la captura lo comparten todas las copias. Aquí fue el propio runtime el que guardó aleatoriedad en caché en el momento equivocado, y la corrección está en el runtime.

A quién afecta: a quien construye un snapshot de arranque de usuario o distribuye un SEA y genera dentro identificadores, tokens o claves con estas funciones. A quién no: a una aplicación normal que se ejecuta con node server.js, que es como funcionan la mayoría de las aplicaciones Node.

La lección dura más que la corrección, como práctica general: nunca derives identificadores, tokens ni secretos de valores creados al compilar. Créalos después de que arranque el proceso. Si distribuyes un SEA o un snapshot, una comprobación rápida es imprimir un valor al arrancar, iniciar el ejecutable dos veces y comparar:

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

Dos líneas distintas significan que cada proceso tiene su propia aleatoriedad. Dos líneas idénticas significan que el runtime no está parcheado o que algo se captura demasiado pronto.

El modelo de permisos es una capa, no el muro

El modelo de permisos de Node.js permite que un proceso limite su propio acceso al sistema de archivos, a la red y a recursos parecidos. Esta versión corrige dos formas de eludirlo, ambas de gravedad baja: CVE-2026-106073, una elusión mediante fs.realpathSync en las ramas 26, 24 y 22, y CVE-2026-106071, una concesión excesiva en el sistema de archivos a través de una búsqueda radix con comodín, solo en la 26. Una tercera corrección baja, CVE-2026-106070, también solo en la 26, impide que ZipFile devuelva bytes de prefijo controlados por el atacante tras fallar la comprobación de una cabecera ZIP.

Aquí baja quiere decir baja, y no voy a exagerarlo. Pero sirve de recordatorio, en sentido general: una restricción dentro del runtime es una capa de defensa. Si la usas para ejecutar código en el que no confías, la frontera de verdad debería estar fuera de Node, en el sistema operativo: un contenedor, un usuario dedicado sin privilegios, montajes de solo lectura.

A quién afecta: a quien confía en el modelo de permisos para contener código no fiable. A quién no: a las aplicaciones que nunca lo activaron, y a las que lo usan como protección extra encima de un aislamiento a nivel de sistema operativo.

El siguiente paso es la misma actualización que para el resto de la versión: 26.12.1, 24.22.1 o 22.23.4 según tu rama. Si distribuyes un SEA o un snapshot, repite la prueba de los dos arranques después de actualizar. Fuente: nodejs.org, Wednesday, October 21, 2026 Security Releases.