A renamed GitHub repo could hand attackers a package’s publishing rights

Bloom Security says npm matched workflows to repository names instead of permanent IDs, leaving 1,500 packages exposed.

CSBadmin
2 Min Read

The npm registry checked the wrong identifier when deciding which GitHub workflow was allowed to publish a package. Researchers at Bloom Security worked out that an attacker who claims a freed repository name can inherit a stranger’s publishing trust, and they count more than 1,500 packages carrying the exposure.

The affected set covers security scanners, authentication libraries and cryptography code, with more than 10 million downloads in total.

Names move, IDs do not

Trusted Publishing, generally available since July 2025, replaced long-lived tokens. A maintainer names the repository and workflow file permitted to cut a release, and GitHub issues a short-lived credential to that workflow when it runs. npm stored the repository as an owner/repo slug, a human-readable string that changes hands when a project is renamed, transferred or deleted. The permanent numeric ID that GitHub also puts in the token went unchecked.

Bloom ran the attack against a package and GitHub organisation it controlled, publishing from a repository under a second organisation that had claimed the abandoned slug. The release came with a valid provenance attestation, which is what makes detection hard.

The team reported the flaw on June 6 and GitHub validated it on June 9. A fix shipped on October 2 that expires unvalidated Trusted Publishing configurations after 48 hours. Maintainers can run npm trust list to see every repository bound to their packages and rebuild any binding that points at a name they no longer hold.

Bloom says the same weakness reaches npm’s GitLab integration, and warns that coding agents install packages by the dozen on developer machines, widening the blast radius.

CSBadmin

The latest in cybersecurity news and updates.

Share This Article
Follow:
The latest in cybersecurity news and updates.