GitHub patches npm Trusted Publishing flaw that allowed package hijacking
Researchers showed how reclaiming old GitHub repository names enabled attackers to publish malicious npm package versions without stealing credentials.
Key points
- Bloom Security identified over 1,500 npm packages vulnerable to takeover via abandoned GitHub slugs.
- The flaw, dubbed SlugFest, stemmed from npm ignoring permanent numeric IDs in favour of human-readable names.
- GitHub shipped a fix on October 2 that adds expiry for unvalidated Trusted Publishing configurations.
npm’s Trusted Publishing feature contained a validation flaw that allowed attackers to publish new versions of legitimate packages. Researchers at Bloom Security demonstrated that the issue enabled takeover without credential theft, affecting more than 1,500 packages with over 10 million total downloads.
Root cause
The vulnerability, named SlugFest, arose because npm verified trusted publishers using GitHub repository slugs rather than immutable numeric identifiers. According to Help Net Security, npm recorded the repository by its owner/repo string but failed to check the permanent IDs included in the token. This design choice meant that trust was tied to a name that could change or be reclaimed.
Attack path
An attacker could register a GitHub repository using a name previously abandoned by a maintainer. By adding a workflow file with the matching filename, the attacker could trigger GitHub to issue a signed identity token. npm would then exchange this token for a publish credential, allowing the attacker to push a malicious version that included a postinstall script.
Affected versions
The issue affected npm packages configured with Trusted Publishing that relied on repository slugs for validation. Bloom Security counted more than 1,500 exposed packages, including security scanners, authentication tools, and cryptographic libraries. The exposed packages averaged several hundred monthly downloads each, with some exceeding a million.
Mitigation
- GitHub confirmed on October 2 that it shipped a fix introducing a 48-hour expiry for unvalidated Trusted Publishing configurations.
- Maintainers are advised to review existing trust relationships to ensure they are correctly bound to current repositories.
- The fix addresses exposure associated with unvalidated configurations, though active exploitation was not observed in the wild.
What to do and how to stay safe: npm
- Audit your npm Trusted Publishing configurations to ensure they reference the correct, current GitHub repository.
- Monitor package dependencies for unexpected version updates or provenance attestation changes from unfamiliar repositories.
- Review GitHub Actions workflows for any packages you maintain to verify they use secure, short-lived credentials.
- Once the vendor provides an update, ensure your build pipelines are configured to validate repository IDs rather than just names.
General security guidance from the TechSec Observer newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What is the SlugFest vulnerability?
It is a flaw in npm’s Trusted Publishing where reliance on repository names instead of numeric IDs allowed attackers to hijack packages by reclaiming abandoned names.
Has the vulnerability been exploited in the wild?
No, Bloom Security stated they have not observed active exploitation, though they successfully demonstrated the attack in controlled testing conditions.
When was the fix released?
GitHub confirmed that a fix was shipped on October 2, which introduces a 48-hour expiry for unvalidated Trusted Publishing configurations.
