CVE-2026-106073 in Node.js
Summary
by MITRE • 10/23/2026
A flaw in Node.js Permission Model filesystem enforcement leaves `fs.realpathSync()` without the required read permission checks. This is an incomplete fix of CVE-2026-21715, which only covered `fs.realpathSync.native()`.
As a result, code running under `--permission` with restricted `--allow-fs-read` can still use `fs.realpathSync()` to check file existence, resolve symlink targets, and enumerate filesystem paths outside of permitted directories.
This vulnerability affects Node.js **26.x**, **24.x**, and **22.x**.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/23/2026
The identified flaw represents a critical bypass in the Node.js Permission Model's enforcement mechanisms for the file system module. Specifically, the function fs.realpathSync() lacks the necessary read permission checks that are enforced by other similar functions within the same API surface. This issue is directly related to CVE-2026-21715, which addressed a similar vulnerability in fs.realpathSync.native(). However, the previous fix was incomplete as it failed to extend these security controls to the standard synchronous implementation of realpathSync. Consequently, applications running with restricted permissions via the --permission flag and specifically limited by --allow-fs-read directives remain vulnerable to unauthorized file system access through this specific function call.
From a technical perspective, fs.realpathSync() is designed to resolve symbolic links and return the absolute path of a given file or directory. In secure environments where strict sandboxing is applied via Node.js permissions, functions are expected to validate that the caller has explicit read access to any paths they attempt to traverse or inspect. The absence of this validation in realpathSync allows an attacker or malicious script to probe the underlying operating system's file structure without triggering permission denials. This capability enables several dangerous operations including checking for the existence of sensitive files, resolving symlink targets which may point outside permitted directories, and enumerating filesystem paths that should remain inaccessible under the current security policy.
The operational impact of this vulnerability is significant in environments relying on Node.js sandboxing to isolate untrusted code or limit application privileges. An attacker exploiting this flaw can perform reconnaissance against the host system by mapping out directory structures and identifying sensitive files such as configuration files, environment variables stored in dotfiles, or other resources protected by standard file permissions but not by the Node.js permission model due to this oversight. This effectively nullifies the security boundary established by --allow-fs-read restrictions for any code path that utilizes realpathSync instead of its native counterpart. The vulnerability affects multiple long-term support and current release lines including versions 26.x, 24.x, and 22.x, indicating a systemic gap in the permission model's coverage across recent Node.js releases.
This flaw aligns with CWE-732: Incorrect Permission Assignment for Critical Resource, as it involves improper assignment of access controls to a critical system resource function. Furthermore, from an adversarial perspective, this vulnerability facilitates ATT&CK technique T1083: File and Directory Discovery, allowing attackers to gather information about the target environment without detection by standard permission checks. It also supports lateral movement or privilege escalation scenarios where knowledge of file locations is required before further exploitation steps can be taken.
To mitigate this risk, immediate action should be taken to update Node.js installations to a patched version that includes fixes for both fs.realpathSync and its native variant. Until patches are available, developers should audit their codebases for usage of fs.realpathSync in contexts where sensitive file system access is restricted and consider replacing it with alternative methods such as fs.access or fs.stat which have been properly secured against permission bypasses. Additionally, implementing strict Content Security Policies and monitoring logs for unexpected filesystem operations can help detect potential exploitation attempts. Organizations should also review their --allow-fs-read configurations to ensure they are comprehensive enough to cover all entry points into the file system module, recognizing that partial fixes may leave residual attack surfaces open.