Production dependencies have known CVEs
how do I know if my npm dependencies have known vulnerabilities Run npm audit and read past the summary line. Most projects sitting untouched for a few months carry at least one high-severity advisory, often in the framework itself or in a transitive dependency pulled in by an SDK. Fix direct issues by upgrading, patch transitive ones with overrides as a stopgap, then gate npm audit in CI so it never regresses silently.
Seen in 33 of 450 scanned projects (7%). Based on 450 Deep Scan runs across production projects.
How to tell you have it
- npm audit reports one or more high or critical severity advisories
- A path traversal or prototype pollution CVE traces back to a package you never installed directly
- The web framework itself has an unpatched high-severity advisory open for months
- Dependabot or Renovate PRs pile up unmerged because nobody owns dependency upgrades
- No audit step exists in CI, so vulnerable versions ship without anyone noticing
Why it matters
Every day a known CVE sits unpatched in a production dependency is a day an attacker can look up the exact exploit for it. Unlike a zero-day, these are public knowledge with working proof-of-concept code, sometimes with automated scanners built specifically to find sites running the vulnerable version. The advisory database is effectively a checklist handed to anyone probing your app.
Transitive dependencies are the part teams miss most often. You audit the packages you added by hand and assume you are covered, but a logging library, an image processor, or an SDK you installed for one feature can quietly pull in a vulnerable sub-dependency several layers deep. npm audit surfaces these, but only if someone actually reads the output instead of glancing at the pass or fail summary.
A high-severity advisory in the web framework itself is the worst case, because the framework touches every request. If it is a request-smuggling or SSRF class bug in something like the HTTP server or routing layer, an attacker does not need any special access to your app, they just need to know which framework and version you run, which is often visible from response headers alone.
Not every advisory is reachable in your actual code path, and treating all of them as equally urgent burns out a team fast. The real work is triage: which vulnerable function does your code actually call, is it exposed to untrusted input, and only then deciding between an immediate patch, a temporary override, or accepting the risk with a documented reason.
How Heygents detects it
Deep Scan runs npm audit and npm outdated against the project's lockfile, reads package.json and the lockfile to identify direct versus transitive advisories, and checks for an audit or dependency-scan step in the CI configuration.
How to fix it
- Run a full audit and read the JSON output, not just the summary The human-readable summary hides which package is direct versus transitive. Use the JSON form to see the real dependency path for each advisory.
- Fix what npm can fix automatically first For advisories with a compatible patched version available, npm can bump the lockfile without touching package.json ranges.
- Patch unreachable transitive advisories with overrides When the vulnerable package is buried under a dependency you cannot upgrade yet, pin the safe version with overrides as a stopgap while you wait for the parent package to update its own range.
- Upgrade the framework itself when the advisory is in it Framework CVEs need a real version bump, not an override, since overrides on the framework package itself commonly break peer dependency resolution. Read the framework's release notes for the patched version and test the upgrade in a branch before merging.
- Gate npm audit in CI so regressions fail the build Add an audit step that fails on high or critical severity so a newly introduced vulnerable dependency cannot merge silently.
Run a full audit and read the JSON output, not just the summary
npm audit --json > audit-report.json
node -e "const r=require('./audit-report.json'); for (const [name,v] of Object.entries(r.vulnerabilities||{})) console.log(name, v.severity, v.via.map(x=>x.title||x).join(', '))"Fix what npm can fix automatically first
npm audit fix
npm ls --all | grep -i deprecatedPatch unreachable transitive advisories with overrides
{
"overrides": {
"vulnerable-pkg": "^2.4.1"
}
}Gate npm audit in CI so regressions fail the build
npm audit --audit-level=highFind this in your own projects, automatically
Heygents runs a read-only Deep Scan across every project you own, finds issues like this one, and hands you a ready-to-run fix an AI agent can execute and verify. A solo developer gets the audit, the backlog and the fix loop in one place.
Open Heygents →Frequently asked questions
Do I need to fix every advisory npm audit reports?
No. Triage first: check whether your code actually calls the vulnerable function and whether untrusted input can reach it. Low-severity advisories in build-time-only tooling rarely matter for a shipped app, but anything reachable from user input in a runtime dependency should be treated as urgent.
Is npm audit fix safe to run without review?
It is generally safe for patch-level bumps within your existing semver ranges, but always run your test suite afterward. Occasionally a patched dependency changes behavior even within semver, especially in packages that were not following semver strictly before the fix.
What is the difference between overrides and upgrading directly?
Overrides force a specific version of a transitive dependency without changing the parent package's declared range, which is fast but can drift out of sync as the parent evolves. Upgrading directly is the durable fix once the parent package publishes a version that supports the patched dependency natively.
How often should I run a dependency audit?
At minimum on every CI run so nothing merges with a new high-severity advisory, plus a scheduled weekly job since advisories get published against versions you already shipped. New CVEs are disclosed constantly against code that has not changed. Make the scheduled run open an issue or send an alert on failure, because a red nightly job nobody is paged about gets ignored within a month.