npm Trusted Publishing Slug Reuse Vulnerability Left 1,500 Packages Exposed to Hijacking via Abandoned GitHub Repo Names

An attacker needed only to register a GitHub repository name that a package maintainer had previously abandoned. This action granted them the ability to push new versions of someone else’s npm package without stealing any credentials. The weakness in npm’s Trusted Publishing feature allowed this takeover by validating trust based on human-readable repository names rather than permanent numeric identifiers.

How it unfolded

• On June 6, Bloom Security reported the issue, dubbed SlugFest, through GitHub’s bug bounty program on HackerOne.
• GitHub validated the vulnerability on June 9, but Bloom noted that subsequent communications went unanswered until late July.
• On October 2, the npm team confirmed they had shipped a fix addressing the exposure associated with unvalidated configurations.

Who is affected

Researchers identified more than 1,500 npm packages exposed to this risk, including security scanners, authentication tools, and cryptographic libraries. These packages collectively recorded more than 10 million total downloads and over one million downloads per month. Although one compromised package is sufficient to cause harm, the scale of exposure creates significant supply-chain risks for developers and CI/CD systems relying on these dependencies.

The fix

GitHub stated it has shipped fixes for the vulnerability. According to Bloom Security researcher Golan Myers, the npm team confirmed the update was released on October 2. The patch introduces a 48-hour expiry period for unvalidated Trusted Publishing configurations. While the technical flaw is addressed, maintainers are still advised to review their existing trust relationships to ensure security.

What made it possible

This incident illustrates a trust-on-first-use validation failure where systems rely on mutable identifiers rather than immutable cryptographic anchors. In supply-chain security, verifying identity via human-readable labels like repository names creates ambiguity when those labels are recycled. Teams usually enforce strict binding between publishing rights and permanent, non-reclaimable IDs. This approach prevents attackers from inheriting trust by claiming abandoned names. Without such checks, an adversary can mimic legitimate infrastructure simply by reusing a previously valid address, bypassing credential theft entirely.

What to do and how to stay safe: npm

• Audit all Trusted Publishing configurations to ensure they reference permanent repository IDs rather than just slugs.
• Monitor package dependencies for unexpected version updates or changes in provenance attestation signatures.
• Review GitHub repository history to identify any renamed or deleted repositories that may have left trust bindings dangling.
• Once the vendor provides an update, apply the fix immediately to enforce expiration on unvalidated trust relationships.

Step-by-step guide: What Is Virtual Patching: How It Works Without Code Changes

General security guidance from the RedTeam Tribune newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Did attackers actively exploit this flaw in the wild?

No, Bloom Security stated they have not observed active exploitation, though they successfully demonstrated the attack in controlled testing.

How many packages were exposed to this risk?

Researchers identified more than 1,500 npm packages that were vulnerable to takeover through reclaimed repository slugs.

What specific change did the fix introduce?

The fix introduced a 48-hour expiry for unvalidated Trusted Publishing configurations to limit the window of exposure.