npm's Trusted Publishing feature was supposed to replace long-lived publishing tokens with short-lived credentials tied to a GitHub repository. Bloom Security found that npm only checked the repository's name, not its permanent numeric ID. When a maintainer renamed, transferred, or deleted the bound repository, the old name became available, and an attacker could register it and add a workflow file with the matching filename to receive a publish credential for a package they did not own.
Bloom counted more than 1,500 npm packages exposed this way, with more than 10 million total downloads and over a million monthly downloads. A malicious version could include a postinstall script that runs automatically on every machine that installs the update. Bloom argues AI coding agents amplify the risk, since agents on a typical endpoint install about 70 packages a month, and close to 350 on developer machines, usually without reviewing the package or maintainer.
GitHub says it has shipped fixes: unvalidated Trusted Publishing configurations now expire 48 hours after creation and can no longer authorize publishing, and a configuration's first successful publish binds it to the repository's immutable identity. Bloom reported the issue on June 6 and GitHub validated it on June 9, but Bloom says follow-ups after July 8 went unanswered. It is unknown whether the flaw was exploited in the wild. Maintainers should run npm trust list and re-create any binding that points to a renamed or transferred repository; users can verify a package's provenance attestation. Bloom says npm's GitLab trusted publishing integration has the same weakness.