Skip to content
loke.dev
Two narrow pipeline paths feeding package blocks through a glowing inspection ring

Fix pnpm ERR_PNPM_AUDIT_BAD_RESPONSE HTTP 410

Fix pnpm audit's HTTP 410 failure by moving from pnpm 10 to v11's bulk advisory endpoint, then migrate ignored advisories safely.

Published 7 min read

The short fix

If pnpm audit fails with ERR_PNPM_AUDIT_BAD_RESPONSE and both reported URLs end in /audits/quick or /audits, read the HTTP status and response body. A 410 response that says to use the bulk advisory endpoint is a package-manager protocol problem, not a vulnerability finding and not proof that your lockfile is corrupt.

Move the audit job from pnpm 10 to a reviewed pnpm 11 release. As of August 5, 2026, the npm registry lists 11.20.0 as the stable pnpm version. Pin it in package.json instead of letting CI choose a moving tag.

{
  "packageManager": "pnpm@11.20.0"
}

pnpm's current audit documentation says v11 queries /-/npm/v1/security/advisories/bulk. The accepted pnpm issue #13033 records pnpm 10 calls to the two older endpoints receiving HTTP 410 from an Artifactory-backed registry. That is the exact failure this guide addresses.

Confirm the failure before upgrading

Match the request path and status, not only the pnpm error code:

  • The pnpm version is 10.x. Reports covered 10.32.1 and 10.33.4, and the current v10 dist-tag is 10.34.5.
  • The first failed URL ends in /-/npm/v1/security/audits/quick.
  • The fallback URL ends in /-/npm/v1/security/audits.
  • Both responses use HTTP 410 and tell the client to use the bulk advisory endpoint.
  • The command stops before it prints a vulnerability report.

If the URL already ends in /advisories/bulk, stop. You have a different failure. For example, npm issue #9804 tracked a July 26 registry incident where the bulk endpoint returned gzip bytes without the matching response header. It affected npm and pnpm, then recovered. Upgrading from pnpm 10 fixes the legacy endpoint choice, but it cannot fix every registry outage.

Why retries are not a durable fix

The npm audit protocol documentation defines the bulk advisory request at /-/npm/v1/security/advisories/bulk. pnpm's current source builds the same path, and its tests assert that exact POST request.

A retry can appear to help if a registry temporarily restores an older endpoint. Several issue commenters saw that happen. It does not change the client protocol, so the next retirement or proxy change can break the same CI job again. The stable repair is to use a client that speaks the current endpoint and confirm that your private registry routes it.

Upgrade the audit path without hiding the result

Use a small upgrade branch and keep the install and audit checkpoints separate:

  • Pin pnpm 11.20.0 in packageManager.
  • Review pnpm 11 configuration changes before regenerating the lockfile.
  • Run the normal frozen install and inspect any failure before changing dependencies.
  • Run a plain audit after the install, without an ignore-registry flag.
pnpm --version
pnpm install --frozen-lockfile
pnpm audit --audit-level=high

The commands are an illustrative verification sequence because your registry, severity policy, and install scripts belong to your project. The important result is that the log shows pnpm 11.20.0 and the audit request completes with an advisory report or a clean result.

Do not use --ignore-registry-errors as proof that auditing works. The pnpm option reference says a non-200 registry response exits with code 0 when that flag is present. It can keep an unrelated build moving, but it also turns a missing audit response into a green process. If security scanning is a required check, fail closed and repair the registry path.

Migrate ignored advisories from CVE to GHSA

The endpoint change also changes the identifiers available to pnpm. The bulk response does not include CVE identifiers, so pnpm 11 filters by GitHub Security Advisory IDs. A v10 list under auditConfig.ignoreCves will not carry the same policy forward.

On pnpm 11.16.0 and newer, put the audit policy in pnpm-workspace.yaml. Start with no ignored advisories, run the audit, then add a GHSA only after somebody records why it is safe to tolerate.

audit:
  level: high
  ignore: []

The YAML is a syntax-checked minimal example for pnpm 11.20.0. The official audit configuration reference says the older v11 names auditLevel and auditConfig.ignoreGhsas remain deprecated aliases until the next major version. Prefer the current audit.level and audit.ignore shape in new changes.

Do not translate CVEs to GHSAs by guessing. Run the current audit, open the advisory link in its More info field, and review the affected range and your exposure before adding an ignore entry.

Check the private registry path

An upgrade changes the client request. It does not guarantee that an internal npm proxy supports the new route. Verify the configured registry without printing credentials:

pnpm config get registry
pnpm audit --audit-level=high

Keep the error's registry host, request path, HTTP status, and timestamp. Redact user info and tokens. Do not paste an entire .npmrc or authorization header into an issue.

Use the result to choose the owner:

  • A 410 on /audits/quick under pnpm 10: upgrade the audit client.
  • A 404, 405, or 410 on /advisories/bulk under pnpm 11: the private registry or proxy needs endpoint support or routing changes.
  • A 401 or 403 on the bulk endpoint: check registry authentication and repository permissions.
  • A 200 response followed by JSON or decompression errors: capture headers and a minimal reproduction, then check registry status and current incidents.
  • A completed report with vulnerabilities: the transport works. Review the advisories instead of treating the nonzero result as an endpoint failure.

Keep the CI audit visible

This GitHub Actions fragment is illustrative. It follows the current setup action inputs and reads the pnpm version from packageManager, but your Node version and required checks may differ.

steps:
  - uses: actions/checkout@v6

  - uses: pnpm/setup@v1
    with:
      runtime: node@24
      install: false

  - run: pnpm install --frozen-lockfile
  - run: pnpm audit --audit-level=high

Keep the audit in its own step so the log shows whether setup, install, transport, or an actual advisory failed. Do not append || true to a required security check. If a registry incident needs a temporary exception, make that exception explicit, time-bound, and owned.

If pnpm setup itself fails while changing versions, use loke.dev's pnpm GitHub Actions bootstrap guide. That article covers a separate pnpm 11.12.0 self-installer crash.

Rush and other managed monorepos need one more check

A tool that wraps pnpm may control the binary, workspace location, and generated configuration. Rush's rush-pnpm documentation warns that direct pnpm commands can use the wrong workspace context. Upgrade the wrapper and its configured pnpm version together instead of dropping an unrelated global binary into the job.

The recent Rush compatibility issue shows why this matters: teams could not treat pnpm 11 as a simple version bump while Rush still generated configuration in the old location. That issue is demand evidence and is now closed. Check the release of your wrapper, then use its supported command path.

If the wrapper cannot yet run pnpm 11, record the audit gap as a blocker and choose a supported scanner or upgrade path. A green job created by ignoring registry errors is not a replacement for a vulnerability report.

Verify the repair

Before merging, confirm all of these:

  • The audit log reports the exact pinned pnpm version.
  • The request uses /advisories/bulk.
  • The private registry returns a valid response, not only HTTP 200.
  • The audit policy uses reviewed GHSA identifiers and the current workspace configuration shape.
  • The frozen install does not rewrite the lockfile unexpectedly.
  • A deliberately vulnerable test fixture or a known advisory can make the audit step fail in a safe test environment.

That last test separates a command that merely exits zero from a control that can still detect a problem. Remove the fixture immediately after the check and never add a vulnerable package to a production branch.

If the pnpm 11 upgrade also moves overrides, patches, or build policy, use the pnpm 11 configuration migration guide and keep that lockfile review in a separate diff.

Sources

Primary technical sources: pnpm audit documentation; pnpm source for the bulk endpoint; npm audit endpoint documentation; pnpm issue #13033; and npm issue #9804.

Demand evidence: the accepted pnpm issue, the linked Rush compatibility thread, and independent repository tasks to restore audit CI and upgrade off the retired endpoint. These reports show current pain; the official docs and source support the technical guidance.