npm says I have vulnerabilities. Am I hacked?

What it actually is

npm audit is a built-in command that reads the packages listed in your package.json and lockfile, sends that list to the registry, and asks for a report of known security flaws in any of them. It runs automatically after every npm install, which is why the warning shows up uninvited. The database behind it is the GitHub Advisory Database, a curated collection of published vulnerabilities in open source packages, the same one that powers GitHub’s Dependabot alerts.

Think of it like a recall notice for car parts. A letter that says “23 parts in your car model have open recalls” doesn’t mean your specific car crashed. It means researchers found flaws in those parts, somewhere, under some conditions. A brake recall is urgent; a glovebox latch barely matters. The letter doesn’t know which parts you actually drive on every day versus which sit unused in the trunk; you have to check that yourself. npm audit works the same way: it flags matches against a public list and leaves the “does this affect me” judgment to you.

Each flaw gets a severity: low, moderate, high, or critical, based on how easily it could be exploited and how much damage it could do. The audit checks your regular dependencies, your devDependencies (tools you only use while building), and any bundled or optional packages, all at once, which is a big part of why the total looks alarming.

Why your AI just did this

Your agent didn’t cause this. npm install runs an audit as a normal side effect, and Lovable, Cursor, Bolt, and Claude Code all run npm install constantly, every time they add a package or scaffold a new project. The moment your node_modules folder gets built, npm checks it against the advisory database and prints whatever it finds.

The count tends to be bigger than the actual risk for two reasons. Many findings sit in devDependencies: test runners, build tools, linters, things that shape your code while you work but never reach the site your users visit. And one flawed package deep in the tree can get pulled in by several other packages, so a single root cause can show up as multiple entries. Your agent doesn’t sort any of that by default; it just reports npm’s own summary line.

When you’ll run into it

You’ll see it right after an install finishes, as a line like:

found 23 vulnerabilities (7 high, 1 critical)

followed by a suggestion to run npm audit fix. Running npm audit on its own (no fix) prints the full report: which package, which severity, and a link to the advisory with details.

You’ll also meet the scarier version, npm audit fix --force. Per npm’s own docs, --force lets the fix “install modules outside your stated dependency range (including SemVer-major changes),” meaning it can jump a dependency past a major version on its own, a version bump that’s allowed to change or remove features entirely. Plain npm audit fix never does that; it only updates within the ranges already in your package.json.

What to check

• Read the summary line first: how many are high or critical, not just the total. A pile of low and moderate findings in build tools is a much smaller deal than one critical finding in a package you import at runtime
• Run npm audit fix (no --force) first. It stays within your existing version ranges, so it’s the safe default
• Before reaching for --force, ask your agent to show you which package it wants to upgrade and to what version. A semver-major jump can change or remove features you rely on
• If a critical or high finding sits in a devDependency only (check the “via” or dependency path in the full report), it’s lower priority than the same severity in a package your live app imports
• After any audit fix, actually run your app and click through the main flow once. An update passing npm audit doesn’t guarantee it didn’t change unrelated behavior
• Leaving every audit warning unread for months is how technical debt builds: harmless one at a time, until one of them becomes the entry point an attacker actually uses

Say it like a dev

Instead of: “npm says I have 23 vulnerabilities, is my app hacked” Say: “npm audit found 23 known vulnerabilities after install. Can you run npm audit fix and tell me what changed, and flag anything left that’s high or critical severity?”

Instead of: “just make the vulnerability warnings go away” Say: “Don’t run npm audit fix —force without telling me first. Show me which packages would jump a major version.”

Instead of: “it says critical, that sounds bad, do something” Say: “This critical finding, is it in a package we actually ship, or a dev-only tool? Fix it if it’s in what we ship.”