npm Retired The Audit Endpoints Your Tooling Still Calls

If your CI started failing with ERR_PNPM_AUDIT_BAD_RESPONSE or a bare 410 from a command that has worked untouched for five years, nothing is wrong with your lockfile. npm turned off the endpoint underneath you.

This is a good case study in how package-manager plumbing actually breaks: not with a deprecation warning and a migration guide, but with a status code, discovered by whichever team's pipeline ran first.

What was turned off

Two endpoints, both long-standing, both undocumented in npm's current public API reference:

Endpoint	Role	Status
/-/npm/v1/security/audits/quick	Quick audit, the common path	410
/-/npm/v1/security/audits	Full audit, the fallback	410
/-/npm/v1/security/advisories/bulk	The replacement	Live, documented

In the GitHub community thread that finally pinned this down, GitHub Support's line was that "after July 15, 2026 the old endpoints will be fully retired," and described the earlier failures as a scheduled brownout. Maintainers on that thread — pnpm's and Yarn's among them — said they received no advance notice or migration guidance (community discussion #192768). The affected list in that thread covers pnpm audit, Yarn 1 Classic's yarn audit, and OWASP Dependency-Check's npm, pnpm and Yarn Classic analyzers.

The new endpoint returns much less

This is the part that made the migration non-trivial. The old audit endpoints took your dependency tree and handed back a finished report. The bulk endpoint is closer to a lookup table.

Per npm's registry API documentation, you POST a flat object of package name to an array of version strings. You get back an object keyed by package name, where each advisory carries id, url, title, severity, vulnerable_versions, cwe and cvss. That is the whole payload.

What is not in there: which of your dependencies pulled the vulnerable package in, whether it is a dev or production dependency, what version fixes it, and the severity totals that audit prints at the end. pnpm's migration pull request (pnpm#11268) spells out what the client now has to do itself: walk the lockfile for finding paths, count vulnerabilities by severity, classify dev versus prod, infer patched versions, and canonicalise advisory IDs. A URL swap it was not.

Where each package manager stands

pnpm

pnpm's docs state plainly: "Since v11, pnpm audit queries the registry's /-/npm/v1/security/advisories/bulk endpoint" (pnpm audit). pnpm 11.0 shipped that change on 28 April 2026. The 10.x line was never backported — the open issue reports failures through v10.33.0 and every earlier 10.x (pnpm#11265). If you pin pnpm in CI, which you should, that pin is the bug.

Yarn

The breakage reported in the community thread is Yarn 1 Classic's yarn audit. Yarn 1's own documentation still describes the command as sending JSON to the npm registry and offers no deprecation note. Modern Yarn exposes a different command, yarn npm audit, which is a separate code path and is not named as broken in that thread. If you are still on Yarn 1 and gating merges on yarn audit, that gate is now decorative.

npm itself

The npm CLI already prefers the bulk endpoint. Worth knowing, though: npm's own audit docs still describe a fallback in which, if the bulk endpoint fails or returns invalid data, npm submits the full package tree to the slower quick-audit path. That documented fallback now lands on a 410. The docs lag the registry — treat the fallback as gone, not as a safety net.

Your ignore list probably stopped working too

Here is the silent failure that will cost someone a week. The bulk endpoint does not return CVE identifiers, so pnpm's CVE-based suppression had nowhere to match. The 11.0 release notes record the rename directly: auditConfig.ignoreCves becomes auditConfig.ignoreGhsas, and the docs add that the old setting "is no longer recognized."

Read that carefully. Not "warns". Not "still works". Unrecognised. Every advisory you had deliberately triaged and suppressed is back in your output, and the upgrade that unsuppressed them also fixed your broken audit, so it looks like the upgrade found new vulnerabilities. Replace each CVE-YYYY-NNNNN with its matching GHSA-xxxx-xxxx-xxxx before you upgrade, not after.

One further wrinkle from the same docs: before v11.16.0 these settings were named auditLevel and auditConfig.ignoreGhsas, and the deprecated names keep working until the next major. So a config written this month and a config written last year can both be valid and mean different things — check yours against the version you actually run, and keep a formatted copy of your resolved config where you can read it, which is what a JSON formatter is for.

Private and proxying registries are the unanswered question

A reviewer on the pnpm pull request asked the obvious thing: what about people using private registries? If your Artifactory, Verdaccio or Nexus instance proxies npm but implements only the old audit routes, the client-side migration does not help you — the endpoint your client now calls does not exist on the host it calls.

Test it directly rather than inferring from CI output. One POST against your registry with a two-package body tells you whether the bulk route is implemented. If you would rather run that check from application code than a shell, a curl-to-fetch converter turns the request into something you can drop into a health check.

What to actually do this week

Four steps, in order:

1. Grep your pipelines for audit and check whether any of them can actually fail. A step that 410s and gets swallowed by continue-on-error is worse than no step.
2. Migrate CVE ignores to GHSA ignores, then move the pnpm pin to 11 or later.
3. On Yarn 1, stop pretending. Either move to modern Yarn's yarn npm audit or replace the gate with a scanner that maintains its own advisory pipeline.
4. Probe your private registry for the bulk route before you roll the upgrade to every repo.

The broader lesson is about dependency surface you did not choose. Registry endpoints are infrastructure your build depends on as surely as a package version does, and they carry no lockfile. It is the same class of exposure we wrote about when npm ended classic token publishing in publishing without tokens, and it is why comparing tools on their maintenance behaviour rather than their feature list keeps paying off. If you are auditing what sits in your toolchain, the developer tools directory and the open-source listings are a reasonable place to start.

FAQ

Why does pnpm audit return ERR_PNPM_AUDIT_BAD_RESPONSE?

Because pnpm 10.x and earlier call the retired quick-audit endpoint, fall back to the retired full-audit endpoint, and get HTTP 410 from both. The fix is upgrading to pnpm 11 or later, which calls the bulk advisories endpoint instead.

What replaced the npm quick audit endpoint?

POST /-/npm/v1/security/advisories/bulk. It takes a flat map of package names to version arrays and returns advisories with id, url, title, severity, vulnerable_versions, cwe and cvss — no dependency paths and no patched versions.

Does yarn audit still work?

Yarn 1 Classic's yarn audit is listed among the broken commands in the GitHub community thread. Modern Yarn's yarn npm audit is a different command and is not named there.

Do I have to rewrite auditConfig.ignoreCves?

Yes, if you use pnpm. The bulk endpoint does not return CVE identifiers, so pnpm renamed the setting to auditConfig.ignoreGhsas and no longer recognises the old one. Convert each CVE to its GHSA identifier before upgrading.

Will my private registry be affected?

Possibly. If it implements only the legacy audit routes, upgrading your client moves the failure rather than fixing it. Send one POST to the bulk path on your own registry and check the response before rolling the upgrade out widely.

---

An endpoint is a dependency. It just isn't one you can pin.