npm audit for Vibe Coders: What the Warnings Mean and What to Actually Fix

You run npm install and get:

12 vulnerabilities (5 moderate, 3 high, 1 critical)

To address all issues, run:
  npm audit fix --force

Should you panic? Should you run that command? If you built your app with Lovable, Bolt, Cursor, Claude, Grok or ChatGPT, you may not even know what half the packages in your project do. This guide explains what npm audit is telling you and how to deal with it without breaking your app.

What npm audit actually does

Your app depends on packages, and those packages depend on other packages. A typical React or Next.js project pulls in hundreds of them. npm audit compares the exact versions in your lockfile (package-lock.json) against a database of publicly reported security advisories and lists any matches.

It tells you:

• which package is affected (often one you never installed directly),
• how severe the advisory is (low, moderate, high, critical),
• the dependency path, meaning how it got into your project,
• whether a fixed version is available.

What it doesn't tell you is whether the vulnerable code is actually reachable in your app. That part is your judgement call.

Why it matters: real npm incidents

Dependency problems aren't just theory:

• September 8, 2025: after a maintainer's npm credentials were phished, attackers published malicious versions of 18 widely used packages, including chalk, debug and ansi-styles. Researchers at Aikido reported the code was built to run in the browser and redirect crypto wallet transactions.
• September 15, 2025: the Shai-Hulud worm started spreading through npm. It ran during install, stole credentials such as npm and GitHub tokens, and used them to publish infected versions of more packages. CISA reported more than 500 compromised packages.

Once a malicious version is known, it shows up in advisory databases, and that's exactly what audit tools check against. Running them regularly is how you find out you installed a bad version.

Step 1: Run it properly

npm audit                  # everything
npm audit --omit=dev       # only packages that ship to production

Using pnpm or yarn?

pnpm audit
yarn npm audit             # Yarn 2+ (Berry)
yarn audit                 # Yarn 1 (classic)

Start with --omit=dev. A vulnerability in a dev-only tool (a test runner or linter, say) is usually much lower risk than one in code that runs on your server or in users' browsers. Note that build tools like Vite are dev dependencies but still matter while you're developing locally.

Step 2: Triage what you see

Work through issues in this order:

1. Critical and high, in production dependencies. Fix these before launch.
2. Anything marked as malware or a malicious version. Treat this as an incident, not a warning (see below).
3. High in dev dependencies. Fix when you can, especially for tools that run a dev server.
4. Moderate and low. Batch them up and handle them in regular updates.

For each high or critical issue, read the advisory (npm audit prints a link). Ask: does my app use this feature? A flaw in a package's command-line mode doesn't matter much if you only use it as a library. When in doubt, update.

Step 3: Fix safely

Try the safe fix first:

npm audit fix

This applies updates allowed by the version ranges in your package.json, which are usually non-breaking.

Be careful with npm audit fix --force. It can install major version upgrades, which may contain breaking changes. On a vibe-coded app with no tests, that's how you end up with a blank white screen. If you use it:

1. Commit everything first so you can roll back (git commit -am "before audit fix").
2. Run it.
3. Run npm run build and click through your app's key flows.
4. If something breaks, git checkout . and fix packages one at a time instead.

Update one package directly:

npm install some-package@latest

When the vulnerable package is buried deep and its parent hasn't updated, you can force a safe version using overrides in package.json:

{
  "overrides": {
    "vulnerable-package": "^2.3.1"
  }
}

Then run npm install. pnpm uses pnpm.overrides and Yarn uses resolutions. Overrides can break the parent package, so test afterwards.

A paste-ready prompt for Cursor:

"Here is my npm audit --omit=dev output: [paste]. For each high or critical issue, explain whether it affects production code, then propose the smallest safe fix (patch/minor update, direct upgrade, or an override). Don't run npm audit fix --force. List any major version upgrades separately with the breaking changes I should check."

If audit flags a malicious package

A vulnerability is a bug. Malware is an attack. If a package version is flagged as malicious, as happened in the 2025 incidents:

1. Don't run your app or install scripts on that machine until it's cleaned up.
2. Remove the bad version: delete node_modules, clear the cache (npm cache clean --force), pin a known-good version, and reinstall.
3. Rotate credentials that were on that machine or in that CI environment: npm tokens, GitHub tokens, cloud keys, and anything in your .env. Shai-Hulud specifically went after these.
4. Check your GitHub account for repos, branches or workflows you didn't create.

Habits that keep the number low

• Commit your lockfile. It pins exact versions, so every install is reproducible and auditable.
• Use npm ci in CI and deployments. It installs exactly what's in the lockfile.
• Don't add packages casually. Before your AI tool installs something, check it's the real, maintained package and not a look-alike name.
• Turn on GitHub Dependabot alerts so you hear about new advisories.
• Remove what you don't use. Fewer packages means fewer problems.
• Python too: if your project has a requirements.txt or pyproject.toml, pip-audit does the same job.

Get the full picture in one scan

npm audit only covers npm. Your repo might also have Python packages, leaked keys in old commits, or a .env file that should never have been pushed. Run a free ShipCheck scan on your GitHub repo (public, or private via Connect GitHub). It checks the npm, pnpm, yarn and Python lockfiles in your repo against the OSV vulnerability database with osv-scanner, runs gitleaks over your files and last 100 commits, and flags .env/.gitignore mistakes. You get a 0–100 score in plain English so you know what to fix first.