Node.js Permission Model flaw over-grants filesystem access

A flaw in Node.js Permission Model enforcement can over-grant filesystem access across radix-tree prefix boundaries. Under --permission, an attacker who is granted access to one path can abuse boundary handling to read from or write to paths outside the intended filesystem allowlist. This vulnerability affects Node.js main, 22.x, 24.x, and 26.x.

The Node.js project identifies active release lines 22.x, 24.x, and 26.x as affected. The version boundaries in the record and advisory are:

• Node.js 22.x: 22.23.1 and earlier are affected; the confirmed security release is 22.23.2.
• Node.js 24.x: 24.18.0 and earlier are affected; the confirmed security release is 24.18.1.
• Node.js 26.x: 26.5.0 and earlier are affected; the confirmed security release is 26.5.1.
• The description also names Node.js main as affected, but it does not provide a specific affected or fixed revision for that branch.

The flaw is in Node.js Permission Model enforcement, where path matching across radix-tree prefix boundaries can grant access beyond the path that was authorized. When running under --permission, an attacker who has been granted access to one path can abuse boundary handling to read from or write to paths outside the intended filesystem allowlist.

This is an access-control weakness classified as CWE-284. The record characterizes the attack as local, requiring low privileges, low complexity, and no user interaction. The public details do not specify the exact path construction or boundary predicate, so the precise target paths beyond the allowlist cannot be determined from the available evidence.

Exploitation requires the attacker to be able to run or influence a Node.js process started with --permission and to have some filesystem access granted to that process. The record characterizes the attack as local, requiring low privileges, low complexity, and no user interaction.

The record does not mark the vulnerability as known exploited and does not identify a public exploit. The SSVC entry shown in the consulted data records exploitation as none at the time of its decision; that status is time-scoped and does not guarantee that exploitation will not emerge later.

The flaw can break the access-control boundary that the Node.js Permission Model is intended to enforce between permitted paths and the rest of the filesystem. The confirmed technical outcomes are unauthorized reads or writes to paths outside the allowlist; the record describes high confidentiality and integrity impact and does not identify an availability impact.

Scope can change because access beyond the intended boundary may reach resources outside the application’s original control scope. However, the flaw does not by itself establish operating-system privilege escalation or administrative access; actual reach remains constrained by the process user and filesystem permissions. Organisational consequences may include data exposure, configuration changes, or modification of application files, depending on the deployment.

Organizations using the Node.js Permission Model as a boundary between an application and the filesystem may have weaker isolation than intended.

• Data files, secrets, configuration, or source code outside the allowlist may be readable if the Node.js process identity has corresponding operating-system permissions.
• Files outside the allowlist may be modified or overwritten, creating a risk of data integrity loss or changed application behavior.
• The practical impact depends on the process user, operating-system filesystem permissions, and the paths included in the allowlist.
• The record does not describe a breach or identify a specific victim, so it does not establish that any organization’s data was accessed.

1. Upgrade Node.js 22.x to 22.23.2, Node.js 24.x to 24.18.1, or Node.js 26.x to 26.5.1, according to the deployed release line. These are the security releases that the Node.js project identifies as fixing the Permission Model flaw.
2. If using Node.js main, move to a revision confirmed by the Node.js project to include the fix; the available evidence does not provide a specific revision for this branch.
3. Recheck images, lockfiles, base images, and the runtime actually used after upgrading so that an older Node.js binary is not left in the deployment path.
4. Until upgrading is possible, do not treat --permission as the sole filesystem security boundary. Use operating-system, container, or sandbox access controls as defense-in-depth, and reduce the sensitive data accessible to the process.
5. No vendor-specific workaround is provided in the available evidence. After patching, review workloads that ran untrusted or semi-trusted code under affected releases.

1. Inventory all Node.js binaries, container images, and runtimes, and identify processes launched with --permission.
2. Determine the filesystem allowlist applied to each process, together with the user, service account, or workload identity running it.
3. Compare deployed releases with the affected and fixed boundaries in affected_summary. Do not treat enabling the Permission Model as proof that the allowlist is being enforced correctly.
4. Review operating-system, container, or sandbox audit telemetry for Node.js processes reading or writing paths outside their intended allowlists. This is precautionary monitoring, not a vendor-defined IOC.
5. Absence of matching log events does not prove that a system is safe, especially where filesystem auditing is incomplete or logs have been overwritten.