The change closes a window where a renamed or deleted repository name could pass publishing trust to a new owner.
npm changed trusted publishing on October 2. A configuration that has never completed a publish now expires 48 hours after creation and can no longer authorize a release. One successful publish validates the configuration and removes the deadline.
The gap it closes is structural. Trusted publishing ties a package to a repository or project name, and those names can change ownership. A configuration left waiting for a future release is a standing grant to whoever controls the name by then. If the repository identity changes, npm requires a new trust relationship and a fresh 48-hour window. Ordinary edits do not reset the clock. Expired configurations stay visible in package settings but stop counting toward per-package limits, so recreate one to restart the window.
npm also rejects trusted publishing tokens minted from GitHub Actions issue_comment events. That joins the existing block on pull_request_target. Publishing workflows should use push, release, or workflow_dispatch.
Audit any package where you configured OIDC publishing ahead of time and never ran a release. If your workflow still triggers on comments, change the event before the next publish, or npm will refuse the token.
Coming in July 2026, npm v12 disables automatic install scripts, git dependencies, and remote URL resolution by default. Every frontend team needs an allowlist before the upgrade lands.
1 source
A coordinated campaign injected malicious code into 14 widely-used npm packages last week. We break down the affected packages, detection steps for your lockfile, and the one CI flag that catches this.
1 source
A valid provenance attestation carried the Shai-Hulud worm through the package's own release workflow, and its dead-man switch punishes a fast token revoke.
3 sources