How vulnarable can NPM be from CVEs of these dependencies?

[tjuhaszrh]

🏷️ Discussion Type

Question

Body

Hi,

I would like to ask about some guidance when it comes to CVEs reported against npm's own dependencies.

We get reports on a near-weekly basis against npm dependencies such as minimatch, node-tar, brace-expansion, and undici, with CVEs usually centered around some sort of unsanitized input.

We have on previous occasions received feedback—for example regarding node-tar in npm/cli#8917—that npm is not vulnerable to a dependency's CVE due to npm-specific filtering.

I would like to better understand whether it is possible for these CVEs to be exploited within the context of standard npm usage. For example, how could an attacker actually trigger the latest brace-expansion DoS vulnerability within the expand() function through standard npm commands?

---

Key areas I am trying to figure out:

1. How are inputs routed to these dependencies?
   For example, in the case of brace-expansion's DoS vulnerability (CVE-2026-13149) in the expand() function: does npm ever pass unvalidated, third-party package data (like fields in a fetched package.json or arbitrary package names) into these expansion and matching libraries? Or are these utilities only invoked on local configuration, deterministic paths, and command-line arguments explicitly provided by the system administrator?

2. How does the project treats these transitive CVEs?
   For example, does the project distinguish between "offline/local-only CLI execution risks" (where an attacker already needs local execution privileges to exploit npm) versus "remote package-registry parsing risks" (where a malicious package published to registry metadata could trigger a crash/execution)?

3. Resources for self-assessment:
   Are there any community resources, write-ups, or past issue analyses you would recommend that demonstrate how to audit the reachability of a sub-dependency vulnerability specifically within the npm CLI codebase?

---

I understand that this is a very broad question, but from our POV, it is necessary to determine how vulnerable our clients will actually be before we start blindly patching. I would appreciate it if anyone could share their insight on how the project deals with this sort of CVE report, or point me towards some resources that could help me understand the possible attack vectors of these unsanitized input CVEs.

[henderson-01]

@tjuhaszrh

The presence of a CVE in one of npm's transitive dependencies does not, by itself, mean that the npm CLI is vulnerable.

Whether npm is actually affected depends on two things:

1. Whether npm executes the vulnerable code path.
2. Whether attacker-controlled input can reach that code path.

For example, CVE-2026-13149 in brace-expansion describes a denial-of-service in the library's expand() function when processing specially crafted input. The advisory identifies the vulnerable function, but it does not state that every project depending on brace-expansion is exploitable. Whether an application is affected depends on how (or whether) it calls that function.

NVD:
https://nvd.nist.gov/vuln/detail/CVE-2026-13149

This is also consistent with previous npm discussions. For example, in npm/cli#8917, the maintainers explained that although a dependency had a reported vulnerability, npm CLI itself was not considered vulnerable because of how it used that dependency rather than simply because the dependency existed in the dependency graph.

npm/cli#8917

So, for a CVE like this, the questions that matter are:

• Does npm ever call the vulnerable function?
• If so, can untrusted input (such as registry metadata, package manifests, tarball contents, etc.) reach that function?
• Or is it only used with trusted/local inputs such as command-line arguments, configuration, or filesystem paths?

Without establishing that call path, the existence of the vulnerable package in npm's dependency tree alone is not sufficient to conclude that npm CLI is exploitable.

I think guidance from the npm maintainers on those specific questions would be valuable, because it would allow downstream consumers to assess whether a reported dependency CVE is actually reachable and exploitable within the context of normal npm CLI usage.

Ultimately, whether a specific dependency CVE is reachable within npm CLI can only be established by examining how npm invokes the affected dependency, for example, through a code audit of the relevant call sites or confirmation from the npm maintainers. The dependency advisory alone is not sufficient to establish that npm is affected, because it describes the vulnerability in the library itself, not how any particular application uses it.

Hope this helps

[initial-d]

A practical way to assess these reports is to treat them as reachability questions, not just dependency-version questions.

For the brace-expansion example, the key is that npm does not normally call brace-expansion directly. It is usually reached through minimatch, so I would audit the minimatch call sites first.

A quick code search in npm/cli shows direct minimatch usage in places such as:

• lib/utils/get-workspaces.js
• workspaces/libnpmdiff/lib/untar.js
• workspaces/arborist/lib/release-age-exclude.js
• workspaces/arborist/lib/query-selector-all.js

That gives you a concrete starting point for the reachability review:

1. Identify the vulnerable function.

   • For brace-expansion, the question is whether attacker-controlled patterns can reach brace expansion through minimatch.

2. Map the direct npm call sites.

   • Search for minimatch( and new Minimatch( in npm/cli.
   • For each call site, record the source of the pattern argument.

3. Classify the input source.

   • Local/admin-controlled: CLI arguments, .npmrc, workspace config, local package paths.
   • Registry/package-controlled: package names, package.json metadata from downloaded packages, tarball paths, archive entries.
   • Mixed: lockfiles or workspace definitions that may be committed by someone else in a repo.

4. Decide whether standard npm usage gives an attacker control.

   • If the pattern comes from local config or a command line option, the risk is closer to local/administrator-controlled DoS.
   • If the pattern comes from registry metadata or tarball contents without filtering, that is much more interesting because a malicious package could trigger it during install/view/diff/audit/etc.

5. Build a tiny reproducer per call site.

   • Example shape: a package/workspace/lockfile/tarball that places the crafted value exactly where that npm call site reads its pattern.
   • Run it with the specific npm command that reaches that code path.
   • Measure whether it hangs/crashes before concluding exploitability.

For brace-expansion specifically, I would pay special attention to libnpmdiff/lib/untar.js, because npm diff/untar code is closer to package/tarball input than workspace config is. Workspace matching in get-workspaces.js is more likely to be local project configuration, so it may be less relevant to a remote registry-driven threat model.

This distinction also explains why maintainers sometimes say “npm is not vulnerable” even when a transitive dependency has a CVE: the vulnerable library is present, but the vulnerable function may only be called with constrained/local inputs, or not called in the affected way.

A useful report to npm maintainers would be structured like this:

Dependency CVE:
Affected function:
npm/cli call site:
Input source:
Can a package author control it remotely? yes/no
Reproducer command:
Observed impact:

That gives maintainers something more actionable than a dependency tree alert. It also lets downstream consumers separate “must patch immediately because registry/package input reaches it” from “dependency scanner finding, but only local trusted input appears reachable.”

[Aaiyub-shaikh]

The key distinction is "dependency contains a CVE" != "npm is vulnerable." Reachability is what matters.
A practical way to evaluate these reports is to work backwards from the vulnerable API instead of the dependency tree:

1. Identify the vulnerable entry point. For example, if the advisory is against brace-expansion's expand() function, determine every location where npm (or one of its direct dependencies) actually invokes that function.

2. Trace the data flow. Ask whether the input reaching that API is:
   Hard-coded by npm.
   Derived from trusted local configuration.
   User-supplied CLI arguments.
   Parsed from registry metadata (package.json, package names, manifests, tarballs, etc.).
   Only the last categories generally indicate a remotely exploitable path.

3. Determine attacker control. A dependency vulnerability is only relevant if an attacker can influence the specific data that reaches the vulnerable API. If npm sanitizes, validates, or never routes untrusted data into that code path, the CVE may be unreachable in practice.

4. Classify the threat model. I find it useful to separate reports into:
   Remote reachability: malicious registry content or package metadata.
   Local reachability: attacker already controls CLI arguments or configuration.
   Developer-only reachability: requires executing arbitrary code in the user's environment first.