Guide · pnpm

pnpm audit not working? Here’s why — and what to do instead

pnpm audit almost always “stops working” for one reason: it’s a network call to a registry audit endpoint, and that endpoint isn’t reachable — a private registry that doesn’t implement it, an air-gapped or proxied CI runner, or a blocked firewall. Below: how to tell which one you’ve hit, the fix for each, and a way to scan your pnpm-lock.yaml that needs no audit endpoint at all.

Updated 26 Jul 2026 · by the depproof team

First, why `pnpm audit` breaks

pnpm audit doesn’t analyze anything locally. It sends your dependency tree to your configured registry’s audit endpoint and displays whatever advisories come back (that data traces to the GitHub Advisory Database). So it only works when that endpoint exists and is reachable — and in real-world setups, it frequently isn’t. As of 2026 it may not exist at all: the endpoint pnpm v10 calls has been withdrawn.

One cause that hit everyone — and four that depend on your setup

The endpoint was retired — HTTP 410. Check this first, because it has nothing to do with your environment. npm put the legacy /-/npm/v1/security/audits and /audits/quick endpoints into a brownout in April 2026 and retired them fully after 15 July 2026. Every pnpm release up to and including v10 calls them, so pnpm audit returns 410 for everyone on v10.x, from any network, against any registry. Yarn Classic (v1) is affected too. npm, Yarn Berry and pnpm v11+ are not — they already use the newer bulk advisories endpoint.
Fix: upgrade to pnpm v11 or later, which queries /-/npm/v1/security/advisories/bulk instead. One upgrade gotcha: auditConfig.ignoreCves is no longer recognised — the bulk response carries no CVE ids, so exclusions move to audit.ignore keyed by GHSA- identifiers.
Your registry has no audit endpoint. Private and mirror registries — Verdaccio, JFrog Artifactory, Sonatype Nexus, GitHub Packages — often don’t implement the npm audit API, so the call errors or returns nothing.
Fix: on pnpm v11+, point audit at the public registry if policy allows — pnpm audit --registry=https://registry.npmjs.org/. On v10 and earlier this no longer helps: the endpoint it would reach is the retired one, so you get a 410 from the public registry too. If you’re on a private registry because you can’t reach the public one, the built-in audit can’t work here — see the lockfile approach below.
Air-gapped or network-restricted CI. No route to a registry audit service means no results — and often a non-obvious error.
Fix: a registry-based audit fundamentally can’t run offline. Use a scanner that reads the lockfile and checks advisory data you run yourself instead.
A proxy or firewall is blocking it. Corporate egress proxies frequently block the audit request even when installs work.
Fix: configure pnpm’s proxy settings (https-proxy / proxy), or route around it with the lockfile approach.
Registry misconfiguration. A registry set to a host that doesn’t answer audit calls returns errors.
Fix: confirm the registry in your .npmrc / pnpm config points somewhere that actually serves audits, or override it per-command with --registry.

Notice the pattern: every one of these fixes runs into the same wall — if you can’t reach a working public audit endpoint, the built-in pnpm audit can’t help you. That’s the case for most locked-down, private-registry and CI environments — and, for four months in 2026, it was the case for everyone at once, because the endpoint itself was withdrawn. A check that depends on someone else’s live service can be switched off without your involvement, and the failure looks exactly like a clean result if you are not reading exit codes.

The durable fix: scan from the lockfile, no audit endpoint

Instead of asking a registry to audit your tree, resolve pnpm-lock.yaml directly and check each component against OSV.dev — open, portable advisory data you can run on your own infrastructure. It needs no registry audit endpoint at all, so a private registry, a mirror or a proxy stops nothing. depproof does exactly this, as a GitHub Action or one container.

Option 1 · GitHub Action

# .github/workflows/vuln-scan.yml
name: vuln-scan
on: [pull_request]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: depproof/depproof-action@v1
        with:
          file: pnpm-lock.yaml
          fail-on: high         # critical | high | medium | low | none

Option 2 · Docker container (any CI)

docker pull ghcr.io/depproof/depproof:v0

# scan the pnpm project from the lockfile — no install, no audit endpoint
docker run --rm -v $PWD:/work -w /work ghcr.io/depproof/depproof:v0 \
  scan pnpm-lock.yaml --fail-on high --html --output-dir /work

It resolves the full transitive tree from the lockfile, flags known CVEs and known-malicious versions, and exits non-zero at or above your fail-on threshold — so it drops into a pipeline step where pnpm audit couldn’t run.

Honest scope

Coverage tracks OSV. depproof surfaces what OSV records for your dependencies (OSV aggregates GitHub Advisories plus other sources, and OpenSSF malicious-package data). It doesn’t run its own behavioral malware analysis or reachability analysis.
Works with pnpm, npm, and yarn lockfiles. Scan the committed lockfile — it’s the exact picture of what you ship.

Frequently asked questions

Why is pnpm audit not working?

As of 2026 the most common cause is not your setup at all: npm retired the legacy audit endpoints that pnpm v10 and earlier call, and they now return HTTP 410 for everyone. pnpm v11 fixed this by moving to the registry bulk advisories endpoint, so upgrading pnpm resolves it. Beyond that, pnpm audit works by sending your dependency tree to your configured registry’s audit endpoint and getting back advisories, so it also fails or returns nothing whenever that endpoint isn’t reachable or doesn’t exist: a private/mirror registry (Verdaccio, JFrog Artifactory, Sonatype Nexus, GitHub Packages) that doesn’t implement the audit API, an air-gapped or network-restricted CI runner, a corporate proxy or firewall blocking the request, or a registry configured to a host that returns an error for audits. The common thread is that pnpm audit is a network call to a service — no reachable audit service, no results.

How do I fix “pnpm audit endpoint returned an error” on a private registry?

Most private and mirror registries don’t implement the npm audit endpoint, so pnpm audit can’t work against them. Check your pnpm version first: on v10 and earlier, pointing audit at the public registry no longer helps, because the legacy endpoint it calls was retired and returns 410 from anywhere. On pnpm v11 or later you can point audit at the public registry with pnpm audit --registry=https://registry.npmjs.org/ if your policy allows outbound access, or — if you’re on a private registry precisely because you can’t reach the public one — use a scanner that reads the lockfile directly and checks a portable advisory database, rather than one that depends on a registry audit endpoint.

Is pnpm audit broken for everyone, or just me?

If you are on pnpm v10 or earlier, it is broken for everyone. npm put the legacy /-/npm/v1/security/audits and /audits/quick endpoints into a brownout in April 2026 and retired them fully after 15 July 2026; both now return HTTP 410, so the call fails regardless of your registry, network or configuration. Yarn Classic (v1) is affected for the same reason. npm audit, Yarn Berry and pnpm v11 and later are not, because they use the newer bulk advisories endpoint. The fix is to upgrade pnpm to v11 or later — and note that the upgrade also replaces auditConfig.ignoreCves with audit.ignore keyed by GHSA identifiers, because the bulk endpoint does not return CVE ids.

Does pnpm audit work offline or air-gapped?

No. pnpm audit requires network access to a registry audit endpoint, so it does not work offline or in an air-gapped environment. To scan for vulnerabilities without that dependency, you need a tool that resolves your pnpm-lock.yaml locally and checks components against advisory data you can host or bundle yourself — which is exactly the gap depproof fills.

Why does pnpm audit return different results than npm audit?

Both query a registry audit endpoint backed by the GitHub Advisory Database, but they can differ because of how each resolves and dedupes the tree, which dependencies are included (for example production-only vs including devDependencies), and the exact advisory data at the moment of the call. A clean pnpm audit is not proof there are no vulnerabilities — it reflects one data source, reachable at one moment, over one view of your tree.

What can I use instead of pnpm audit?

For CI and locked-down or private-registry setups, use a scanner that reads pnpm-lock.yaml straight from the lockfile and checks every component against OSV — open, portable advisory data — on your own infrastructure, with no registry audit endpoint required. depproof does this as a GitHub Action or a single container, resolves the full transitive tree, and returns a pass/fail exit code you can gate a PR on.

Scan npm dependencies for vulnerabilities — the same lockfile-based scan for npm.
Why npm & pnpm audit miss vulnerabilities — how audit actually works and where it falls short.
Zero findings is not zero risk — when an empty result means nothing was wrong, and when it means nothing was read.
npm license checker — the license side of the same scan.

Run your first scan → Read the docs More guides

depproof is free for open source and teams under $1M revenue — see pricing. The action README is the source of truth for exact inputs and the current release. depproof is not affiliated with pnpm, npm, or Snyk; product names are used nominatively.