npm audit Shows 47 Critical Vulnerabilities. Here Is Which Ones Actually Need Fixing.

Run npm audit --json to get structured output. The JSON format gives you the fields you need to answer each question without parsing prose output.

Question 1: Is this package in devDependencies or dependencies?

In npm audit --json, look at the nodes array for each finding. Trace the affected package back through the dependency chain. If the root of the chain is a devDependency in your package.json, this package does not ship in your production build unless your build process explicitly bundles dev deps (rare and a separate problem).

DevDependency vulnerabilities that do not run in CI/CD pipelines with access to production secrets or sensitive data carry near-zero risk. Document them, set a reminder to fix them when a compatible patch arrives, and move on.

Exception: if the devDependency runs in a CI/CD pipeline that has access to production credentials, repository secrets, or deployment infrastructure, treat it as production-equivalent.

Question 2: Does your code reach the vulnerable function?

This is the reachability question. Most high-severity npm audit findings exploit a specific function within the vulnerable package. If your code calls the package but never invokes the vulnerable function, the vulnerability is unexploitable from your application.

The via field in npm audit --json output names the specific vulnerability within the package. Cross-reference this against the GitHub Advisory Database entry for the CVE: it identifies which function is affected. Then search your codebase for calls to that function through the affected package. If there are none, the vulnerability is unreachable.

Question 3: Is there a fix available without breaking changes?

The fixAvailable field in npm audit --json tells you whether npm audit fix can resolve the issue. If fixAvailable: true, run npm audit fix in a branch, run your test suite, and deploy the fix. This should take under 30 minutes for most projects.

If fixAvailable: { name, version, isSemVerMajor: true }, a fix exists but it is a major version bump that may include breaking changes. This requires dedicated testing. Schedule it as a dependency upgrade, not an emergency patch.

Treat an npm audit finding as requiring immediate remediation when all three of the following are true:

1. The vulnerable package is in dependencies (not devDependencies)
2. Your code makes calls that reach the vulnerable function (or you cannot confirm it does not)
3. A fix is available via npm audit fix or a minor/patch version bump

In this scenario: create a branch, run npm audit fix, run your full test suite, verify no regressions, and merge to main within 48 hours.

For production-impacting, actively exploited vulnerabilities (those with a CISA KEV entry or a GitHub Advisory severity of Critical with a proof-of-concept exploit), reduce the window to 24 hours.

Common examples requiring immediate action:

• serialize-javascript ReDoS in production bundle: attackers can send crafted input through your application to cause CPU exhaustion
• axios SSRF in production API client: attackers can manipulate URLs your backend fetches
• express path traversal: attackers can access files outside the intended web root

A finding qualifies for documented deferral when any of the following apply:

• Package is in devDependencies and does not run in privileged CI/CD environments
• Package is a deep transitive dependency (A depends on B which depends on C: the vulnerability is in C, and your code calls A through a path that never reaches C's vulnerable function)
• No fix is available (upstream maintainer has not published a patched version)
• The fix requires a major version bump with breaking changes that would require significant application rework

Deferral requires documentation. Create a ticket that records: the CVE ID, why you deferred, the conditions under which deferral is no longer acceptable (e.g., 'if a proof-of-concept exploit is published' or 'if a compatible fix is released'), and the review date. Without this documentation, deferred findings become permanently ignored findings.

For devDependency findings with no fix available, the deferral documentation is enough. For production dependency findings where you cannot fix due to breaking changes, document compensating controls (WAF rules that block the exploit input pattern, input validation that prevents the vulnerable code path from being reached externally).

The Sapphire Sleet npm supply chain attack in 2026 backdoored 144 npm packages including easy-day-js in 88 minutes. Running npm audit on a project using the compromised easy-day-js package would have shown zero findings: because the backdoored version had no CVE. It was a clean package with attacker code inserted into it. No known vulnerability. No advisory. No audit finding.

This is the critical limitation of npm audit: it detects known vulnerabilities in registered packages. It does not detect:

• Malicious packages with no CVE (typosquatting, account takeover, dependency confusion)
• Packages with backdoored versions published before discovery
• Packages with malicious postinstall scripts
• Internal packages with hardcoded credentials or data exfiltration

Defense against supply chain attacks requires different controls than npm audit: lockfile integrity verification (commit package-lock.json and verify its hash in CI), package provenance attestation (enabled in npm via --provenance flag since npm 9.5), restricting --ignore-scripts in production installs, monitoring for unexpected outbound network connections from build processes, and using software composition analysis tools that check package behavior in addition to known CVEs.

For organizations that had Sapphire Sleet exposure, the remediation steps are in the Sapphire Sleet npm Supply Chain Attack post.