Deno: BYONM module resolution allows `package.json` main path traversal to bypass `--allow-read` restrictions

Vulnerability

When Deno was used with the BYONM (Bring Your Own node_modules) feature enabled (nodeModulesDir: "manual"), the module resolver resolved npm packages directly from a user-managed node_modules tree. When resolving a require("pkg") call, the resolver read the main field from the package's package.json, joined it to the package directory, and loaded the result as a module. However, the resolver did not validate that the resolved path remained within the package's node_modules// directory. A malicious package.json whose main field contained .. segments (e.g., "../../../secret.json") could traverse upward, escaping the package root and even the node_modules directory entirely. This affected any Deno version that supports BYONM mode with nodeModulesDir: "manual" before the fix. [1][2]

Exploitation

To exploit this vulnerability, an attacker must be able to introduce a malicious npm package into the node_modules tree used by a Deno application running in BYONM mode. This could occur through a compromised dependency or a direct addition to the project. No special network position or authentication is required beyond the ability to place the package. The attacker creates a package.json with a main field containing path traversal sequences pointing to a target file (e.g., "../../secret.json"). When the Deno application executes require("evil-pkg"), the resolver reads the attacker-controlled package.json, constructs the path by joining the package directory (node_modules/evil-pkg/) with the traversal sequence, and loads the resulting file. The BYONM permission check at the time only verified that the path contained a node_modules component, which was still true after traversal, so the file was read without consulting the --allow-read allowlist. [1][2]

Impact

A successful attack allows an unprivileged actor to read arbitrary files on the filesystem that the OS user can access, bypassing the --allow-read permission restrictions. This violates the confidentiality of sensitive data such as secrets, configuration files, or any .json file (the PoC specifically targeted JSON files because the resolver parsed JSON entrypoints). The attacker cannot directly achieve code execution or write files, but reading sensitive data can lead to further compromise (e.g., credential theft). The scope is limited to files reachable by the OS user; the same file accessed via a direct Deno.readTextFileSync() call would have been correctly blocked. [1][2]

Mitigation

The vulnerability was fixed in Deno version 2.2.0, released on 2025-02-25. Users running Deno with BYONM mode (nodeModulesDir: "manual") are strongly advised to upgrade to that version or later. For those unable to upgrade immediately, the only workaround is to disable BYONM mode (i.e., use a different nodeModulesDir setting such as "auto" or rely on Deno's built-in vendoring) and ensure that the execution environment is free of untrusted packages. Affected Deno versions are not on the CISA KEV list as of this writing. [1][2]