npm Trusted Publishing Slug Validation Gap Exposed Thousands of Packages
Researchers found that abandoned GitHub repository names allowed attackers to hijack publishing rights for over 1,500 npm packages, a flaw now patched.
Key points
- Bloom Security identified more than 1,500 npm packages vulnerable to takeover via reused GitHub repository slugs.
- The flaw in Trusted Publishing allowed attackers to publish malicious code without stealing maintainer credentials.
- GitHub shipped a fix on October 2 that introduces a 48-hour expiry for unvalidated configurations.
Bloom Security researchers discovered a validation flaw in npm’s Trusted Publishing feature that exposed more than 1,500 packages to potential takeover. The vulnerability, dubbed SlugFest, allowed attackers to push new versions of packages by reclaiming abandoned GitHub repository names, according to Help Net Security.
Root cause
npm’s Trusted Publishing relies on OpenID Connect to verify publishers, avoiding long-lived tokens. However, the system checked the human-readable repository slug rather than the permanent numeric ID, according to CSO Online. When a maintainer renamed or deleted a repository, the old slug became available for anyone to claim, bypassing identity checks.
Attack path
An attacker could register a new repository using the freed slug and add a matching workflow file. npm would issue a publish credential for the package, even though the attacker did not own it, Bloom Security reported. The researchers demonstrated this end-to-end, publishing a version from a different organization’s repository with a valid provenance attestation.
Affected versions
- More than 1,500 npm packages were identified as exposed by Bloom Security.
- These packages collectively received more than 10 million downloads, with over a million monthly, according to Help Net Security.
- Categories included security scanners, authentication tools, and cryptographic packages, CSO Online noted.
Mitigation
- GitHub confirmed a fix was shipped on October 2, introducing a 48-hour expiry for unvalidated Trusted Publishing configurations, according to Bloom Security researcher Golan Myers.
- The update addresses the exposure associated with unvalidated configurations, though maintainers should review existing trust relationships.
- No active exploitation in the wild was observed, but the technical capability was confirmed in controlled tests.
What to do and how to stay safe: npm
- Audit your npm Trusted Publishing configurations to ensure they reference immutable repository IDs rather than just names.
- Monitor package dependency updates for unexpected changes in provenance attestation or publisher identity.
- Review organizational repository hygiene to prevent accidental name reuse or abandonment of critical build assets.
- Implement additional integrity checks for automated publishing workflows to detect unauthorized credential usage.
Step-by-step guide: Unpatched Software Myths: Why Common Beliefs Fail to Protect You
General security guidance from the BlueTeam Insider 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?
Bloom Security stated they have not observed active exploitation, though they successfully demonstrated the attack in controlled conditions.
How was the vulnerability discovered and reported?
Bloom reported the issue via GitHub’s bug bounty program on HackerOne on June 6, and GitHub validated it on June 9.
What specific fix did GitHub implement?
The fix, shipped on October 2, introduces a 48-hour expiry for unvalidated Trusted Publishing configurations to prevent stale slugs from being used.
