What is NPM Dependency Confusion? How Organisation Namespace Issues Lead to RCE (2025 Guide)

A Dependency Confusion attack, also known as a substitution attack, occurs when a malicious actor uploads a package with the same name as an internal or private dependency to a public package registry. If the development environment is misconfigured, the package manager may inadvertently download the public (malicious) package instead of the intended internal one.

What are NPM Packages?

NPM packages are reusable components or libraries that developers distribute through the Node Package Manager (NPM) registry. These packages can be either public—accessible to the entire developer community—or private, restricted to specific teams or organizations. In many cases, companies create internal or local packages exclusively for internal use within their systems and infrastructure.

What is a Dependency Confusion Attack?

NPM Dependency Confusion occurs when a developer uses a private or internal package that does not exist in the public NPM registry. If an attacker identifies the name of this internal package and publishes a malicious package with the same name—and often a higher version number—to the public registry (e.g., npmjs.com), the package manager may mistakenly download and install the attacker’s version.

This is especially likely in environments where packages are automatically updated without strict scoping or proper configuration, potentially leading to the execution of untrusted code.

How can you find it in the JS Files?

You can identify NPM packages referenced within JavaScript files by using a simple grep command. For example:

curl '<js_file_url>' | grep -Eo 'node_modules/(@[^/]+/[^/]+|_[^@]+@[^/]+|[^/]+)' | sort -u

This command performs the following:
curl fetches the JavaScript file from the given URL
grep -Eo extracts occurrences of package paths inside node_modules
sort -u ensures the results are unique and sorted

This is particularly useful when auditing third-party JavaScript files to detect any potentially risky or unusual dependencies.

How to check for Dependency Confusion?

If you discover a package name referenced in a JavaScript file, you can manually verify whether it exists on the public NPM registry by visiting:

https://registry.npmjs.org/<package name>

If the URL returns a 404 Not Found, it indicates that the package is not currently published on the public registry — which means it may be an internal or private dependency.

If you find a package path like the following in a JavaScript file:
node_modules/@<org name>/<package name>

It indicates the use of a scoped package—typically associated with an organization on NPM. To verify whether the organization exists, visit:

https://www.npmjs.com/org/<org name>

If this URL returns a 404 Not Found, it suggests that the organization namespace is unclaimed on NPM.

✅ If the organization is available, and the scoped packages are referenced in production code, it may be possible to register the organization and publish malicious packages under that namespace — leading to a critical dependency confusion and potential org-wide takeover.

⚠️ Always follow responsible disclosure practices if you identify such a vulnerability in a third-party application.

Using Jsmon to Spot Missing or Malicious Node Modules

Jsmon offers three flexible options to upload and analyze JavaScript files:

• Scan a Domain
  Scan a domain, and Jsmon’s built-in reconnaissance tools will actively scan it to discover and collect JavaScript files.

• Scan JavaScript URL Directly
  Scan .js URL of any host for analysis.

• Upload a File Containing JavaScript URLs
  Scan a text file containing a list of JavaScript file URLs, and Jsmon will fetch and scan them automatically.

After the scan is complete, navigate to the JS Intelligence section and select the Invalid Node Modules tab. This view will display any invalid, missing, or unpublished NPM packages detected in the scanned JavaScript files.

Impact

If the malicious package you publish is installed and executed by an internal server, it can lead to Remote Code Execution (RCE). This occurs because the internal system downloads and runs your code—giving you the ability to execute arbitrary commands within the organization's infrastructure.

In such cases, you're not just getting network-level interaction; you're potentially executing code behind the firewall, which significantly elevates the risk and severity of the vulnerability.