Node randomUUID duplicate values from startup snapshots

Nine of the ten CVEs in the October Node.js release are fixed by upgrading. Node randomUUID duplicate values are the exception: CVE-2026-106074 bakes the entropy cache for crypto.randomUUID() and crypto.randomInt() into user-land startup snapshots and single executable applications, and an artefact you built before the fix keeps emitting the same values no matter which Node you installed afterwards. If you ship an SEA or use a snapshot to cut cold-start time, the patch is a rebuild.

It is rated Medium, it got almost no coverage next to the Brotli bug, and it is the one most likely to be closed in your tracker without actually being fixed.

Why Node randomUUID duplicate values appear at all

The Node.js advisory describes the flaw in one sentence, and it is worth reading literally: "crypto.randomUUID() and randomInt() entropy caches are saved into user-land startup snapshots and SEAs, so every process repeats the same values". It affects the 26.x, 24.x and 22.x lines, and it is fixed in 26.12.1, 24.22.1 and 22.23.4.

The mechanism follows from what a snapshot is for. Both functions keep a buffer of random bytes rather than calling into the system CSPRNG on every invocation, because that buffer is what makes them fast. A V8 startup snapshot captures heap state after your initialisation code has run, so the process can skip that work on boot — and if the buffer has been filled by then, the filled buffer is part of the captured state. Every process that restores from that snapshot starts with the same bytes and walks the same sequence.

So the values are not weakly random. They are identical, deterministically, across every process and every machine running that artefact.

Who is actually affected, and who is not

This needs user-land snapshots or an SEA. It does not describe ordinary node server.js deployments, containers that run a normal entrypoint, or the built-in snapshot Node ships with itself.

How you ship	Affected?	What the fix is
Single executable application (SEA)	Yes	Upgrade Node, then rebuild the executable
--build-snapshot / --snapshot-blob	Yes	Upgrade Node, then regenerate the blob
Plain node app.js, normal container	No	Upgrade Node

One honesty note on remediation. The advisory itself publishes no workaround or mitigation text for any of the ten CVEs, including this one, so "rebuild as well as upgrade" is our reading of the mechanism rather than an instruction we are quoting. We think it is unavoidable: a patched runtime restoring a pre-patch snapshot is still restoring a cached buffer. If you have an SEA in production, test it rather than taking our word for it.

There is a second reason to rebuild that has nothing to do with entropy. The same release updated bundled dependencies — c-ares on all three lines, OpenSSL on 24.x and 22.x, SQLite on 22.x, Undici on all three, and the CA certificate store for the eMudhra intermediate CA compromise. An SEA carries its own copy of the runtime, so a stale executable is also carrying a stale trust store and a stale TLS stack. The 24.22.1 release notes list what moved.

Where a repeated UUID actually hurts

The impact is entirely about what you used the value for, which is why a Medium rating is defensible and also why it can be badly wrong for a specific system.

• Idempotency keys. Two processes generating the same key means a payment retry is silently deduplicated against an unrelated request, or a genuine second charge is dropped.
• Session and token identifiers. If randomUUID() is what makes a session unguessable, it is now guessable from any copy of your binary.
• Filenames and object keys. Uploads overwrite each other, and the collision looks like a storage bug for weeks.
• Correlation and trace IDs. Cheapest case: your traces merge and your logs become unusable for exactly the incident you are debugging.
• Database primary keys. A unique constraint turns a security bug into a loud outage, which is the good outcome.

The ordering matters for triage. If your UUIDs only ever become filenames and trace IDs, this is a Medium and a scheduled rebuild. If one of them is an idempotency key on a payment path, treat it as the highest-priority item in the release and rotate anything long-lived that was derived from it.

The test that would have caught it

Almost every test suite that asserts on UUID uniqueness asserts it within one process, which is precisely the case that still passes. The assertion that fails here crosses a process boundary:

# Generate from two separate runs of the shipped artefact
./my-sea-app --emit-id > /tmp/run1
./my-sea-app --emit-id > /tmp/run2

# Any output means the artefact repeats itself
comm -12 <(sort /tmp/run1) <(sort /tmp/run2)

Run it against the built artefact, not against source in a dev shell, because the snapshot only exists in the build output — the same reason a release gate has to audit what the build actually ships rather than what the repository contains. A suite that only ever sees node test.js cannot see this class of bug at all.

This is the general shape worth taking from a Medium CVE: the gap was not in the code, it was in what the tests could observe. Coverage reports would have shown this path fully exercised, which is the usual reason coverage hides more than it reveals.

What to do if you ship an SEA

Upgrade to 22.23.4, 24.22.1 or 26.12.1. Rebuild every snapshot and every executable from the patched runtime, and treat artefacts built earlier as suspect rather than merely old. Add the cross-process uniqueness check above to the pipeline that produces them. Then go and look at what those values were used for, because that is where the actual remediation is — and if any of them became a credential, a key or an idempotency token, rotating it is part of the fix, not a precaution.

Single executable applications are a relatively new way to ship Node, and this is the first CVE we have seen that punishes the build artefact rather than the runtime. Expect more, and make sure your test automation runs against the thing you actually distribute.