pnpm Audit: Find and Fix Dependency Vulnerabilities Safely

Short answer

Run pnpm audit to identify vulnerable dependencies, trace the affected package back to its direct parent, and make the smallest reviewed update that removes the risk. If the parent has no compatible fix, use a documented pnpm.overrides entry temporarily, then enforce the updated pnpm-lock.yaml in CI with --frozen-lockfile.

Start with the real dependency path

pnpm audit
pnpm why <vulnerable-package>

The audit severity is important, but the path explains how the package entered the repository and where it runs. A vulnerable production parser deserves a different urgency from an isolated developer tool, although CI dependencies can still expose high-value credentials.

Apply the narrowest fix

Prefer this order:

1. Upgrade the direct dependency that introduces the vulnerable package.
2. Make a compatible pnpm update and review the resulting lockfile.
3. Apply a temporary override when the patched transitive version is known to be compatible.
4. Replace or remove the parent dependency when no safe patch exists.

{
  "pnpm": {
    "overrides": {
      "<vulnerable-transitive-package>": "<patched-version>"
    }
  }
}

Document the advisory, parent package, patched version, owner, and removal date next to every override. An override is a deliberate exception, not a permanent collection of unexplained pins.

Decide whether the finding is urgent

Prioritize remediation by where the affected code runs and what it can access. A runtime dependency reachable from untrusted input, or a CI package that can read deployment credentials, may need immediate action. A development-only package can still matter, but document its exposure and a target fix date. Record the advisory, affected paths, selected fix, and verification evidence in the pull request so reviewers can distinguish a deliberate temporary exception from an ignored alert.

Verify before merging

pnpm install
pnpm audit --audit-level=high
pnpm test
pnpm run build
git diff -- package.json pnpm-lock.yaml

CI should use pnpm install --frozen-lockfile so an undeclared lockfile change fails instead of creating a new dependency graph during deployment.

For the equivalent npm and Bun commands, see JavaScript Dependency Security: Managing Vulnerabilities with npm, Bun, and pnpm. If an AI coding tool proposed the package, use the AI-generated package review checklist before any install.