Try the demo Check my app free

Launch and other stacks

How to find and fix vulnerable npm dependencies

To find vulnerable npm dependencies, run npm audit (it reads your lockfile and checks every installed version against published advisories), then upgrade direct dependencies to the fixed version and use overrides in package.json for vulnerable packages pulled in by others. Not every advisory matters to your app, so read what the vulnerable function is and whether your code uses it.

By Manraj Singh Dhillon, technical founderChecked 10 Nov 20264 min read

TL;DR

  • Your lockfile pins exact versions of every package, including ones you never installed directly. Those versions are what get checked.
  • npm audit --omit=dev shows what ships to production; OSV (osv.dev) is an open database you can query for any package version.
  • Fix: upgrade the direct dependency, or force a fixed version of a transitive one with overrides. Test afterwards.
  • Prioritise advisories in code that handles user input or runs on your server.

Where dependency vulnerabilities come from

An app built with AI tools typically has a few dozen direct dependencies in package.json and several hundred packages in total once their own dependencies are counted. The lockfile (package-lock.json, pnpm-lock.yaml, yarn.lock or bun.lock) records the exact version of every one. When a security problem is found in a package, an advisory is published naming the affected versions and the version that fixes it. Your app is affected if your lockfile pins an affected version.

Templates and generated projects can start out pinned to older versions, and nothing updates them on its own while the app keeps working.

Find them with npm audit

terminal
# Everything, including build tools
npm audit

# Only what ships to production
npm audit --omit=dev

# Machine-readable, for CI
npm audit --omit=dev --audit-level=high --json > audit.json

npm audit sends your dependency tree to the npm registry’s advisory service and reports each match with its severity, the vulnerable path (which package pulled it in) and whether a fix is available. With --audit-level=high it exits non-zero only for high and critical advisories, which makes a sensible CI gate. pnpm and Yarn have their own audit commands.

Look up any package in OSV

OSV is an open vulnerability database that aggregates advisories from GitHub, npm and other ecosystems. Its API answers “is this exact version affected?” without installing anything:

terminal
curl -s https://api.osv.dev/v1/query \
  -d '{"package":{"name":"lodash","ecosystem":"npm"},"version":"4.17.20"}' \
  | head -c 800

The response lists each advisory’s id, summary, affected ranges and fixed version. For example, lodash 4.17.20 is affected by CVE-2021-23337 (command injection through _.template), fixed in 4.17.21. Google’s open-source osv-scanner tool checks a whole lockfile against OSV in one go.

Decide which advisories matter

A match means the version is affected, not that your app is exploitable. Ask three questions of each one:

  1. Does it ship? A bug in a build tool or test runner that never runs in production is lower priority than one in your server or browser code. (A dev server bug can still matter while you develop on an untrusted network.)
  2. Do you use the vulnerable part? The advisory usually names a function or option. A prototype-pollution bug in a function you never call is less urgent than an XSS bug in the Markdown renderer that displays user comments.
  3. Does untrusted input reach it? Bugs triggered by user content (parsers, sanitisers, renderers, upload handlers) or network requests are the ones attackers can reach.

When in doubt, upgrade. It is usually cheaper than the analysis.

Fix them

A direct dependency

terminal
npm install lodash@4.17.21
# or let npm apply the non-breaking fixes it knows about
npm audit fix

Avoid npm audit fix --force unless you have read what it will do: it may install major versions with breaking changes.

A dependency of a dependency

First check whether a newer version of the parent package already depends on a fixed version (npm ls lodash shows who pulls it in). If not, force the fixed version with overrides (npm 8.3 and later):

package.json
{
  "overrides": {
    "lodash": "4.17.21"
  }
}

Run npm install to update the lockfile, then your tests and a manual click-through. pnpm uses pnpm.overrides and Yarn uses resolutions for the same purpose.

No fix available

If there is no fixed version, look for a maintained alternative, remove the dependency if you barely use it, or limit exposure (for example, never pass user input to the affected function) and record the decision.

Keep it that way

  • Commit your lockfile, so what you audit is what you ship.
  • Run npm audit --omit=dev --audit-level=high in CI.
  • Turn on automated dependency update pull requests (GitHub’s Dependabot or similar) and merge them regularly, in small batches.
  • Re-check periodically even when nothing changes: new advisories are published for old versions.

Many of the dependency advisories that matter most in frontend apps are in HTML sanitisers and Markdown renderers, and they matter because user content reaches them. Rendering user content as raw HTML is its own risk even with up-to-date packages: see PL-024.

Sources

The checks behind this guide, each with example code, a self-check and the fix.

PL-023

Dependency with a known vulnerability

PL-024

User content rendered as raw HTML

Free check

Check your app for this, free.

Paste your public repo. PatchLabs rebuilds your database from its migrations, tests it as a visitor, a stranger and the owner, reads the code for keys and risky patterns, and hands you the fix.

Free for your first appNever touches your database

Written by Manraj Singh Dhillon. Last checked 10 Nov 2026. Code samples are synthetic and run against your own project; nothing here names a real app. Spotted a mistake? Tell us.