- Bloom Security says npm trusted a GitHub repository's name, not its permanent ID. It counted more than 1,500 packages whose publishing setup pointed at a name someone else could claim.
- GitHub says it shipped fixes, including a 48-hour expiry for unproven setups. It has not said whether setups that already published are bound to the permanent ID.
- Check your own publishing setups for renamed or deleted repositories, and ask who approves the packages your coding agents install.
Trust is only as strong as the thing it points to. npm's Trusted Publishing pointed to a name. Names can be given up, and then someone else can take them. That is the lesson in a flaw Bloom Security reported, and it reaches well beyond npm.
What Bloom found
Bloom's researchers found a way to publish new versions of another person's npm package. The attacker did not need to steal any password or token. A stranger only had to claim a GitHub repository name that its former owner no longer held.
The report puts the combined downloads of these packages above 10 million, with over a million a month. The researchers ran the attack from start to finish. They did it only on a package and repositories they controlled. Bloom's researcher Golan Myers said nobody yet knows whether attackers used the flaw in the wild.
How the trust broke
Since July 2025, npm has offered Trusted Publishing to everyone. It stands in for publishing tokens that stay valid for a long time. The maintainer pairs a package with one GitHub repository and one workflow file. When that workflow runs, GitHub issues a signed identity token. npm trades it for a publishing credential that lapses within minutes.
The weak point was how npm remembered the repository. It kept the owner/repo text, which GitHub calls a slug. GitHub also gives each repository and owner a number that never changes, even after a rename or transfer. Both numbers travel inside the token. npm did not check them.
So a rename, transfer or deletion freed the old slug. The same happened if the owner account was renamed or deleted. A stranger could then create a repository under that name. They added a workflow with the same file name and ran it. npm treated that run as the real publisher and issued a credential for a package the stranger did not own.
The result also looked legitimate. A release published this way carries a valid provenance attestation, which is a signed record of how it was built. That record names the attacker's repository.
One GitHub safeguard limited the damage. When an account that owns a heavily cloned repository is renamed or deleted, the repository's name cannot be reclaimed. The report sets the bar at more than 100 clones in the prior week. Myers said Bloom allowed for this and counted only names that could still be claimed.
A name is not an identity
Think of a phone number that a carrier gives to a new customer. Your old bank still lists it as yours. Calls meant for you now reach a stranger. npm's trust record worked the same way. The label stayed put while the party behind it changed.
This shows why a signature alone proves little. The signed build record was real. It simply named the wrong party. A check that asks only whether a release is signed will pass. A check that asks who signed, and whether that is still the same party, can catch this.
What GitHub changed, and what it has not said
On October 2, GitHub announced a new limit. A trusted-publishing setup that has never been proven now lapses 48 hours after creation and stops authorizing releases. It becomes validated after its first successful publish. Changing the repository or project identity starts a new 48-hour window.
GitHub made a second change. Workflows triggered by comments on issues can no longer publish through Trusted Publishing. This joins an earlier block on pull_request_target triggers. Affected teams should publish from push, release or workflow_dispatch instead.
Several questions remain. GitHub's statement does not say whether setups that had already published were bound to the repository's permanent ID. npm's documentation says a first successful publish binds a setup to that identity. The 48-hour rule covers only unvalidated setups. So it is not shown to protect the packages already exposed.
The timeline rests on Bloom's account. Bloom says it reported the issue through HackerOne on June 6 and that GitHub validated it on June 9. Bloom says its last reply came on July 8. It says six follow-ups went unanswered. GitHub told Help Net Security it learned of the issue through its bug bounty program and shipped fixes. That statement does not address the dates or the unanswered follow-ups.
Bloom argues AI agents widen the reach
Bloom argues that AI coding agents carry flaws like this further. Its telemetry from dozens of organizations suggests agents add about 70 packages a month on a typical endpoint. On developer machines the estimate is close to 350, before counting dependencies. Bloom says these installs usually happen with no review of the package or its maintainer.
A bad version can include a postinstall script. That is code that fires during installation, with no one clicking anything. Each computer that takes the tainted version would execute it. One hijacked package is enough. The risk grows when no person reads the install list.
Questions to put to your teams
First, which of our npm packages use Trusted Publishing? Has each setup completed a successful publish since the change? Second, have any repositories or accounts that publish for us been renamed, transferred or deleted? Third, do any publishing workflows run from issue_comment events?
On the consuming side, ask who approves the packages that coding agents install. Ask whether install scripts run by default on developer laptops and build servers.
GitHub says it has shipped fixes. It has not said whether already-published setups are now bound to the repository's permanent ID. Until that is clear, the habit of trusting a name is still ours.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: GitHub.
