A design flaw in npm, the main registry for JavaScript software components, left more than 1,500 packages open to being hijacked by anyone who claimed the old name of a renamed or deleted GitHub repository, according to research published by security company Bloom Security and reported by CSO Online Tuesday. The gap sat in Trusted Publishing, a feature built to make software supply chains safer, and it shows how a control meant to eliminate stolen credentials can open a different path for attackers.

What Happened

Trusted Publishing lets a package maintainer link an npm package to a specific code repository, so that automated build systems can publish new versions with short-lived, automatically issued credentials instead of long-lived passwords or tokens that can be stolen.

According to Bloom’s write-up, which the company calls “SlugFest,” npm recorded that link by the repository’s owner and name, such as an organization name followed by a project name, rather than by GitHub’s permanent numeric IDs. The IDs were stored only after the first successful publish. If a linked repository was renamed, transferred or deleted before then, someone else could register the freed name, add a workflow file with the expected filename and obtain a valid credential to publish to a package they did not own. No maintainer account had to be compromised.

RelatedClaude Code Desktop Preview Flaw Could Have Exposed Developers’ Cloud Keys, Researchers Say

Bloom says more than 1,500 packages were exposed, with over 10 million total downloads and more than 1 million a month. CSO Online reported that one package alone exceeds 200,000 monthly downloads and that affected packages include security scanners, authentication tools and cryptographic libraries. Bloom says npm’s GitLab version of the feature was affected too. It has not published the package list.

Bloom says it proved the attack end to end against an npm scope it owns. It has not said whether anyone exploited the gap in the wild.

GitHub’s Fix

GitHub published a changelog entry on Oct. 2 titled “Unvalidated npm Trusted Publishing Configurations Now Expire.” Links that have never been used to publish now expire 48 hours after creation, which GitHub said limits the risk of trusting a repository name after it changes hands. Changing the linked repository requires a new trust relationship. npm also now rejects credentials issued from GitHub Actions comment events. The entry does not mention a reported vulnerability.

Bloom says it reported the issue through GitHub’s HackerOne bug bounty program on June 6 and that it was validated June 9, and that six later follow-ups went unanswered until npm's team replied to the last one, apologized for the lack of communication and confirmed a fix. It argues that npm should verify permanent repository IDs when a link is created, as the Python registry PyPI does.

Why It Matters

Trusted Publishing exists to take long-lived secrets out of software releases. This case shows that swapping a secret for a name check moves the trust problem rather than removing it, because a name can be re-registered by someone else. As Bloom’s post puts it, “A name is not an identity.”

Bloom ties the risk to AI coding agents. It estimates, in vendor research, that an average endpoint installs about 70 agent-selected packages a month, rising to about 350 on developer machines, excluding packages those pull in. “It only needs to be the package an agent chooses,” Bloom researcher Golan Myers told CSO Online.

For security leaders, the lesson is that renaming or deleting a repository is a security event, and that controls on what agents may install matter as much as controls on human developers.

What to Watch

Bloom advises maintainers to list each package’s trusted repositories, confirm every name still points to one they control and recreate links after any rename or transfer. Open questions are whether any package was quietly taken over before the fix, whether npm moves to ID-based checks and whether GitHub comments on the disclosure timeline.