Node.js: randomUUID() in Snapshots und Grenzen des Berechtigungsmodells

Beim Node.js-Sicherheitsrelease vom Oktober 2026 schauen die meisten auf die Bugs mit hohem Schweregrad. Zwei der kleineren Fixes lohnen trotzdem einen eigenen Blick, weil sie Annahmen korrigieren, die man ganz nebenbei trifft: dass crypto.randomUUID() jedem Prozess einen anderen Wert liefert, und dass das Berechtigungsmodell eine Mauer ist. Für die meisten Anwendungen ändert keins von beidem etwas. Für zwei bestimmte Gruppen schon.

Wenn „zufällig“ in jedem Prozess gleich ist

CVE-2026-106074, mit mittlerem Schweregrad bewertet und auf den Linien 26, 24 und 22 behoben, betrifft Startup-Snapshots und Single Executable Applications (SEAs). Die Entropie-Caches hinter crypto.randomUUID() und randomInt() wurden in User-Land-Snapshots und SEAs mitgespeichert. Jeder Prozess, der aus demselben Snapshot oder derselben Executable startete, wiederholte also dieselben Werte.

Zum allgemeinen Hintergrund: Ein Snapshot oder eine SEA ist ein Abbild der Anwendung, dessen Zustand einmal erfasst und dann in vielen Prozessen wiederhergestellt wird. Genau das macht den Start schnell. Es heißt aber auch, dass alles, was zum Zeitpunkt der Erfassung zufällig war, von jeder Kopie geteilt wird. Hier hatte die Runtime selbst Zufall zum falschen Zeitpunkt gecacht, und der Fix steckt in der Runtime.

Betroffen: wer einen eigenen Startup-Snapshot baut oder eine SEA ausliefert und darin mit diesen Funktionen IDs, Tokens oder Schlüssel erzeugt. Nicht betroffen: eine gewöhnliche App, die mit node server.js läuft, und so laufen die meisten Node-Anwendungen.

Die Lehre überdauert den Fix, als allgemeine Praxis: Leite IDs, Tokens oder Secrets nie aus Werten ab, die beim Build entstanden sind. Erzeuge sie erst, nachdem der Prozess gestartet ist. Wenn du eine SEA oder einen Snapshot auslieferst, geht ein schneller Test so: beim Start einen Wert loggen, die Executable zweimal starten, vergleichen.

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

Zwei verschiedene Zeilen heißen: Jeder Prozess hat seinen eigenen Zufall. Zwei identische Zeilen heißen: Die Runtime ist nicht gepatcht, oder irgendetwas wird zu früh erfasst.

Das Berechtigungsmodell ist eine Schicht, nicht die Mauer

Mit dem Berechtigungsmodell von Node.js kann ein Prozess seinen eigenen Zugriff auf Dateisystem, Netzwerk und ähnliche Ressourcen einschränken. Dieses Release behebt darin zwei Umgehungen, beide mit niedrigem Schweregrad: CVE-2026-106073, eine Umgehung über fs.realpathSync auf den Linien 26, 24 und 22, und CVE-2026-106071, eine zu weite Freigabe im Dateisystem durch eine Wildcard-Radix-Suche, nur auf 26. Ein dritter niedriger Fix, CVE-2026-106070, ebenfalls nur auf 26, verhindert, dass ZipFile nach einer fehlgeschlagenen Prüfung des ZIP-Headers vom Angreifer kontrollierte Präfix-Bytes zurückgibt.

Niedrig heißt hier niedrig, und ich will es nicht aufbauschen. Es ist aber eine nützliche Erinnerung im allgemeinen Sinn: Eine Einschränkung innerhalb der Runtime ist eine Verteidigungsschicht. Wer damit Code ausführt, dem er nicht vertraut, sollte die eigentliche Grenze außerhalb von Node ziehen, auf Ebene des Betriebssystems: ein Container, ein eigener Benutzer ohne Rechte, Read-only-Mounts.

Betroffen: wer sich darauf verlässt, dass das Berechtigungsmodell nicht vertrauenswürdigen Code einsperrt. Nicht betroffen: Apps, die es nie eingeschaltet haben, und Apps, die es als zusätzliche Absicherung über einer Isolation auf Betriebssystemebene nutzen.

Der nächste Schritt ist dasselbe Upgrade wie für den Rest des Releases: 26.12.1, 24.22.1 oder 22.23.4, je nach Linie. Wer eine SEA oder einen Snapshot ausliefert, macht nach dem Upgrade noch einmal den Test mit den zwei Starts. Quelle: nodejs.org, Wednesday, October 21, 2026 Security Releases.