Key points
- Bloom Security found that more than 1,500 npm packages were exposed to takeover via the SlugFest flaw.
- GitHub shipped a fix on October 2 that expires unvalidated Trusted Publishing configurations after 48 hours.
- Researchers demonstrated the attack end-to-end but reported no evidence of exploitation in the wild.
npm’s Trusted Publishing feature contained a validation gap that allowed attackers to publish malicious updates to legitimate packages without stealing credentials. GitHub, which owns npm, has released a fix for the issue, dubbed SlugFest by researchers at Bloom Security. The vulnerability affected more than 1,500 packages, which collectively recorded more than 10 million downloads.
In plain English
Trusted Publishing lets maintainers use automated workflows to release software updates without storing long-lived passwords or tokens. The system was designed to verify that a release came from a specific GitHub repository. However, npm originally verified this connection using only the human-readable name of the repository, known as a slug. It did not check the permanent numeric ID that GitHub assigns to every repository.
If a maintainer renamed, transferred, or deleted their repository, the old name became available for anyone to claim. An attacker could create a new repository with that same name, add a matching workflow file, and trick npm into issuing a valid publishing credential. This allowed the attacker to push a new version of the package, potentially containing harmful code like a postinstall script.
The background
Bloom Security researchers identified the flaw and reported it through GitHub’s bug bounty program on HackerOne on June 6. GitHub validated the issue on June 9. The researchers successfully demonstrated the attack in a controlled environment, publishing a new version of a package from a repository belonging to a different organization. Despite this proof of concept, Bloom stated that no active exploitation had been observed in the wild at the time of reporting.
What changes now
GitHub confirmed that a fix was shipped on October 2. The update introduces a 48-hour expiration period for unvalidated Trusted Publishing configurations. A configuration becomes validated and is exempt from this expiry rule after its first successful publish. This change prevents attackers from claiming abandoned repository names and immediately obtaining publishing rights for packages that still trust those old, now-reclaimed slugs.
Who needs to act first
Teams should prioritize reviewing automated publishing workflows for packages that have undergone repository name changes or ownership transfers. Verify that trusted publishing configurations are actively validated and not relying on stale or abandoned repository slugs. If you manage multiple packages, audit your CI/CD pipelines to ensure they are using the latest npm client versions that enforce the new validation rules.
Test your release workflows in a sandbox environment before rolling out changes to production systems to confirm that legitimate builds still succeed. Check with your security team to ensure monitoring is in place for unexpected package versions or provenance attestation anomalies.
Background: Bug bounty programs
A bug bounty program is a formalized agreement where you pay external security researchers to find and report vulnerabilities in your software. It complements internal testing by leveraging diverse expertise to uncover hidden risks that automated scans miss, creating a continuous feedback loop for security improvement.
Read the full guide: Bug Bounty Programs: How External Researchers Secure Your Code
What to do and how to stay safe: npm
- Audit your npm package dependencies for any recent unexpected version bumps or provenance attestation mismatches.
- Ensure your CI/CD pipelines are using the latest npm client that enforces the 48-hour expiry for unvalidated configurations.
- Review your organization’s GitHub repositories for any renamed or deleted projects that may have left trusted publishing links in a vulnerable state.
- Monitor your build logs for any failed validation attempts or warnings related to OIDC token exchanges.
Step-by-step guide: Out-of-Band Patches: Meaning, Risks, and Deployment Reality
General security guidance from the Patch Herald newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What is the SlugFest vulnerability?
SlugFest is a flaw in npm’s Trusted Publishing feature that allowed attackers to hijack packages by reclaiming abandoned GitHub repository names, as npm did not verify permanent repository IDs.
Has the flaw been exploited in the wild?
No, Bloom Security reported that they had not observed active exploitation of the SlugFest vulnerability in the wild at the time of their disclosure.
How did GitHub fix the issue?
GitHub shipped a fix on October 2 that causes unvalidated Trusted Publishing configurations to expire after 48 hours, preventing immediate takeover by attackers claiming old repository names.
