CVE-2026-21636: Permission Model Bypass in Node.js 25

CVE-2026-21636 is a permission model bypass in Node.js 25.x. With the permission flag on, code can still connect to local Unix domain sockets without network permission. NVD scores it 10.0 (Critical) while the Node.js project rates it Medium. The January 2026 security release for 25.x is Node.js 25.3.0, so upgrade and review who relies on the permission model.

What's affected

• Product: Node.js, release line 25.x only
• Condition: the permission model is turned on at startup
• Not affected: the record and the Node.js advisory say the issue applies to users of the permission model on 25.x, and the project says it has no impact on other active release lines
• Fixed version: the Node.js security release of January 13, 2026 lists Node.js 25.3.0 for the 25.x line. Confirm against the release notes for the build you deploy

The score depends on who you ask. NVD lists CVSS 10.0 with a changed scope, and the Node.js project labels the issue Medium in its own release notes. The CVE is not in the CISA Known Exploited Vulnerabilities catalog.

How to check if you're exposed

Two questions decide whether you are exposed. Are you on Node.js 25, and do you run it with the permission model?

node --version

If that prints a 25.x version below 25.3.0, you are on an affected build. Then look for the permission flag in the places that start Node processes:

grep -rn "permission" Dockerfile* package.json .github/ scripts/ 2>/dev/null

Check container images and systemd units too, since the flag is often set there and not in the repository. If nothing uses the permission model, this bypass does not change your risk, though upgrading is still the sensible move.

What to do now

1. Run node --version on every host and image that runs Node.js 25.x.
2. Upgrade to Node.js 25.3.0 or later. Use the project release notes to confirm the version you pick.
3. Find workloads that start Node with the permission model and note which of them depend on the network limit as a security control.
4. Until you have upgraded, do not treat the permission model as a boundary for code you do not trust. Run that code in a container or a separate user account with its own network rules.
5. Pin the Node.js version in your Dockerfiles and CI images so the fix does not drift back out.

Why it matters

The permission model lets you start Node.js with a limited set of rights, so a script can read only certain directories or reach only allowed hosts. In the 25.x line, network limits are still experimental. This flaw is a gap in that experiment: the advisory says Unix domain socket connections were not checked, so code that was denied network access could still connect to local sockets through the net module, the tls module or fetch.

That matters because the inputs involved, such as a URL or a socketPath option, are often influenced by data from outside. The record names the possible outcomes as privilege escalation, data exposure or local code execution, depending on which local service answers on the socket. The weakness class is CWE-284, improper access control: a check that was meant to sit in front of every connection did not cover one kind of connection.

The practical lesson is about what a sandbox promises. A permission flag in a runtime narrows the damage from a mistake, but an experimental one is not a security boundary you should lean on for hostile code. Keep operating system and container controls underneath it.

This is also a good case for knowing where your runtime versions live. Runtime bugs are easy to miss because they are not in your lockfile. A scan of the images you actually ship will list the Node.js version alongside your packages.

Try it yourself

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Node.js January 2026 security releases

Last reviewed: 19 October 2026.