How to Fix npm audit Vulnerabilities

npm audit is the first line of defense for the JavaScript dependencies in your project. It compares every package in your lockfile against the GitHub Advisory Database and prints anything that matches a known CVE. Here is a practical workflow for triaging and fixing what it reports, without shipping a broken build.

What npm audit actually does

When you run npm audit, npm walks your package-lock.json, sends the dependency tree to the registry's audit endpoint, and receives back a list of packages with published advisories. It does not analyze your code; it only knows that a vulnerable version is installed, not whether you call the vulnerable function. That distinction matters when you decide what to fix and what to defer.

Understanding severity levels

Every advisory carries a CVSS-derived severity:

• info - informational; no exploit path.
• low - minor issue, often requiring unusual conditions.
• moderate - real bug, limited impact or hard to reach.
• high - meaningful risk, patch soon.
• critical - remote code execution, auth bypass, or similar; patch now.

Use npm audit --audit-level=high in CI so the pipeline only fails on high and critical issues rather than blocking on noise.

Fix option 1: npm audit fix

npm audit fix installs the newest version of each vulnerable package that still satisfies your declared semver range. It touches package-lock.json but leaves package.json alone. This is the safest fix and should always be your first move. If a vulnerable transitive dependency can be resolved to a safe version within existing ranges, this will do it in one shot.

Fix option 2: npm audit fix --force

--force tells npm to install versions that violate your declared ranges, including major-version bumps. Expect breaking changes. Only use it after committing your current state, and always run your full test suite plus a smoke test of the built app before merging. In monorepos, run it per workspace so a break in one package does not mask others.

Fix option 3: bump the top-level dependency

Most vulnerabilities live in transitive dependencies. If npm audit says lodash is vulnerable but you never installed lodash directly, the fix is to upgrade whatever top-level package pulls it in. Check the tree with npm ls lodash, find the parent, and upgrade it. This is cleaner than forcing overrides because the maintainer has usually already published a patched release.

Fix option 4: overrides and resolutions

When the parent package has not yet released a fix, force the safe version yourself. In npm 8.3+, add an overrides block to package.json:

{
  "overrides": {
    "minimist": "^1.2.8"
  }
}

In Yarn, use resolutions in the same location. Both mechanisms rewrite the lockfile to pin the transitive dep to your chosen version. Test carefully - you are overruling the parent's declared range, which occasionally breaks its assumptions.

When to defer

Not every finding demands a fix today. Reasonable reasons to defer:

• Dev dependencies not shipped. A vulnerable dev-only tool that runs on your build box is much lower risk than a runtime package sent to browsers or servers.
• Unreachable code paths. If the CVE requires calling a function you never invoke - for example, a regex DoS in a code path you do not use - the practical risk is often near zero.
• No published fix. Sometimes the only remediation is waiting; document the decision so it does not silently linger.

Track deferrals in an issue with an expiry date so they get revisited, not forgotten.

Alternative tools

npm audit is fast and free but relatively coarse. For richer signal:

• Snyk adds reachability analysis, license checks, and integrates with pull requests to open fix PRs automatically.
• Socket focuses on supply-chain risk - typosquats, install scripts, obfuscated code - not just published CVEs.
• GitHub Dependabot opens PRs based on the same advisory database and is free for public repos.

Run npm audit in CI as a hard floor, and layer one of these on top for real defense in depth.