npm Trusted Publishing flaw left 1,500+ packages open to takeover via renamed repos

A design weakness in npm's Trusted Publishing feature allowed attackers to publish new versions of other people's packages without stealing a single credential, researchers at Bloom Security have disclosed, according to Help Net Security. Bloom counted more than 1,500 affected packages that together have over 10 million downloads and more than 1 million downloads per month. GitHub, which operates npm, announced a fix on October 2, but it is unclear whether bindings created before the change were retroactively protected.

What happened

Trusted Publishing lets a package be published from a CI workflow using short-lived OIDC credentials instead of long-lived npm tokens. According to Help Net Security's report, npm tied each publishing configuration to a GitHub repository's name, or "slug", rather than to the permanent numeric identifiers GitHub assigns to repositories and accounts, and npm did not check those IDs.

When a maintainer renamed, transferred or deleted the linked repository, or when the owning account was renamed or deleted, the old name became available to anyone. An attacker could register it, add a workflow file with the matching filename and receive a valid publish credential for a package they did not own.

Bloom tested the attack end to end using packages and repositories it controlled. The malicious release even carried a valid provenance attestation naming the attacker's repository, so the signed build record did not reveal the problem. Bloom said npm's GitLab Trusted Publishing integration has the same weakness.

Disclosure timeline

Bloom reported the issue through GitHub's HackerOne bug bounty program on June 6, 2026, and GitHub validated it on June 9. Bloom said its last reply from GitHub came on July 8 and that six later follow-ups, including a mediation request to HackerOne, went unanswered. GitHub announced the fix on October 2.

Under the fix, Trusted Publishing configurations that have not been validated expire 48 hours after creation and can no longer authorize publishing. A GitHub spokesperson said this limits the risk of trusting a repository or project name that changes ownership. GitHub already retires the names of repositories that had more than 100 clones in the week before an owner account is renamed or deleted, which protected some packages but not all.

Who is affected

Bloom researcher Golan Myers said it is not known whether the flaw was exploited in the wild. Bloom is not publishing the affected package names, so users cannot check their dependencies against a list. The researchers stressed that a single hijacked package is enough to cause damage, because a malicious version with a postinstall script runs automatically on every machine that installs it.

Bloom also pointed to AI coding agents as an amplifier, estimating that agents on a typical endpoint install about 70 packages a month and close to 350 on developer machines, not counting dependencies, often without anyone reviewing the package or its maintainer.

What to do

• Maintainers: run npm trust list and confirm that every listed repository still resolves to one you control. Delete and re-create any binding that points to a renamed or transferred repository, and remove the binding before deleting a repository.
• Package consumers: verify that a package's provenance attestation names the repository the project is supposed to come from, and treat unexpected new versions of rarely updated packages with caution.