Node.js Trust Falls: Dangerous Module Resolution on Windows

The issue is straightforward: when Node.js resolves modules, the runtime searches for packages in C:\node_modules as part of its default behavior. Since low-privileged Windows users can create this directory and plant malicious modules there, any Node.js application with missing or optional dependencies becomes vulnerable to privilege escalation.

When a Node.js application calls require(‘bar’), the runtime searches for the module in the following order:

1. C:\Users\Administrator\projects\node_modules\bar.js
2. C:\Users\Administrator\node_modules\bar.js
3. C:\Users\node_modules\bar.js
4. C:\node_modules\bar.js <-- The problem

If the legitimate package is missing, whether due to optional dependencies, development packages removed in production, or installation failures, the resolution search will eventually reach the root of the drive. Any user can create C:\node_modules and place a malicious package there. Once the low-privileged user has populated C:\node_modules\bar.js, Node.js will load and execute it in the context of the current user. In the following case studies, we will provide evidence of how, despite properly following NPM’s guidelines, third-party dependencies end up triggering this vulnerability anytime you launch the application.

Case Studies: Real-World Manifestations

The Optional Dependency Pattern: npm supports optional dependencies to be specified in the project’s package.json file. The recommended pattern for checking for these dependencies is as follows:

This pattern silently catches errors when optional packages are missing, allowing execution to continue. So what’s the problem? On Windows, Node.js will search all the way up to C:\node_modules where an attacker may have planted a malicious replacement. This search behavior mirrors UNIX conventions where /node_modules at the filesystem root is typically only writable by root. Windows systems by default allow any user to create C:\node_modules. Once require is called, Node.js will traverse the search path and execute any matching module it finds.

Important things to note:

1. This pattern can be found in third party libraries deep in a dependency tree, as we will see in the following examples.
2. There is no runtime indication to either the developers or the end users that such a vulnerability exists without looking at the filesystem logs with Procmon.
3. The optional dependency pattern itself would not be dangerous if Node.js did not search for packages in C:\node_modules.

Let’s take a deeper look at both cases and see why this is so dangerous.

Case 1: npm CLI (ZDI-26-043 / ZDI-CAN-25430 / CVE-2026-0775).

Prior to version 11.2.0, npm CLI used a library called “promise-inflight”, which contained an optional dependency on a package called “bluebird”.

When Node.js is installed on the system, npm is included by default without the bluebird package. This vulnerability was introduced when bluebird was removed through a well-intentioned pull request (https://github.com/npm/cli/pull/1438/changes), demonstrating how easy it is for developers to unknowingly create this attack surface.

We can see Node’s package resolution logic at work in the screenshot below:

First, the application looks for the bluebird.js package in the Node.js installation directory. Node.js sequentially searches back to the system root until it finds the package. If an attacker has placed C:\node_modules\bluebird.js, the require call will find, read, and execute the malicious payload in the context of any user running npm on the system.

This vulnerability is especially dangerous because it is triggered when many npm * cli commands are used. Common development commands such as npm install, npm –l, and npm prune will all execute the malicious bluebird.jspackage.

Case 2: Discord (ZDI-26-040/ ZDI-CAN-27057 / CVE-2026-0776/ UNPATCHED)

On April 22, 2025, ZDI received a report for a similar vulnerability in Discord reported by T. Doğa Gelişli. Discord uses the ws WebSocket library, which contains an optional dependency on utf-8-validate for compatibility with older Node.js versions:

Discord does not ship with the utf-8-validate package. As a result, the following Procmon logs show the same behavior as Case 1. Anytime Discord is launched, the attacker controlled C:\node_modules\utf-8-validate.js is executed.

The ws library does support disabling this check via the WS_NO_UTF_8_VALIDATE environment variable, but this requires the consuming application (Discord) to set it explicitly. Here’s a quick video demonstrating the bug by popping the calc app when opening Discord:

The vulnerability pattern described in this blog stems from a deliberate design decision by Node.js maintainers. While Node.js's position that “applications should trust their filesystem” may hold true on properly administered UNIX systems, it creates a systemic vulnerability on Windows where low-privileged users can write to C:\node_modules. Without a fix from Node.js, the burden silently falls on application developers.

Making matters worse, the vulnerable code may not live in the application code itself. The optional dependencies that trigger this behavior could come from third-party libraries buried in the dependency tree as we saw with both Discord and npm CLI.