A new npm Trusted Publishing vulnerability called SlugFest lets attackers hijack packages without stealing credentials. Security firm Bloom Security disclosed the flaw this month. GitHub had spent four months validating and quietly fixing it first. The bug exploited npm’s trust in a GitHub repository’s name instead of its permanent ID. Once a maintainer renamed or deleted a repo, attackers could claim the old name. From there, they could publish malicious updates to packages with millions of downloads.
What Is npm Trusted Publishing?
npm Trusted Publishing lets maintainers publish package updates straight from a CI/CD workflow. It replaces long-lived npm tokens with short-lived, signed credentials. The feature became generally available in July 2025 and is built on the OpenSSF Trusted Publishers standard. A maintainer links a package to a specific GitHub repository and workflow file. When that workflow runs, GitHub issues a signed OpenID Connect (OIDC) identity token. npm exchanges that token for a publish credential scoped to one release. GitLab CI/CD and CircleCI support the same basic model.
What Is the SlugFest Flaw?
Bloom Security researcher Golan Myers found that npm validated trust the wrong way. Instead of checking a repository’s permanent numeric ID, npm checked only its owner and name string, often called a slug. GitHub repository names are not permanent. A maintainer can rename a repo, transfer it, or delete it outright. Once that happens, anyone can claim the old slug. An attacker can register a new repository under that exact name. They add a workflow file matching the expected filename. npm then treats the attacker’s repository as the trusted source. No stolen password or token is required anywhere in the chain. Bloom demonstrated the attack end to end on its own test package. The resulting malicious release still carried a valid provenance attestation.
How Many Packages Were Exposed?
Bloom’s research turned up over 1,500 npm packages with an exploitable trust binding. Combined, those packages have logged over 10 million downloads. They still pull in more than 1 million downloads every month. One package alone accounts for over 200,000 of those monthly downloads. The exposed set spans authentication libraries, cryptographic packages, and security scanners, the kind of dependency teams rarely question. Bloom declined to name the specific packages, citing ongoing risk. The firm also warned that npm’s GitLab Trusted Publishing integration carries the identical weakness.
Why AI Coding Agents Raise the Stakes
Bloom argues the real danger lies in how teams install code today. AI agents now pick and install most dependencies themselves, with little oversight. Across dozens of monitored organizations, Bloom measured roughly 70 agent-installed packages per endpoint each month. On dedicated developer machines, that figure climbs to nearly 350 packages a month. Those numbers exclude transitive dependencies pulled in automatically. As DevX has covered, generative AI is reshaping how developers write and ship code. Agents rarely review every dependency they add. That shift turns a quiet repo-name trick into something with a much larger blast radius.
Disclosure Timeline and GitHub’s Fix
The disclosure process took months longer than the fix itself. Bloom reported SlugFest through GitHub’s HackerOne program on June 6, 2026. GitHub validated the report just three days later. Communication then stalled, and Bloom’s last reply from GitHub arrived on July 8. GitHub left six follow-up messages unanswered, including a mediation request through HackerOne. A fix did not arrive until a changelog entry on October 2, 2026, nearly four months after validation. Unvalidated Trusted Publishing configurations now expire 48 hours after creation. A configuration only becomes permanent once it completes one successful publish inside that window. npm also now rejects trusted-publishing tokens triggered by GitHub Actions issue_comment events.
What Maintainers and Teams Should Do Now
Maintainers should treat this as a prompt to audit, not just patch and move on. Check every package’s trusted publisher setup under Packages, Settings, Trusted Publishing on npmjs.com. Confirm each linked repository still belongs to your organization. If you renamed, transferred, or deleted a repo, remove the old binding and recreate it. Consumers of a package can check that its provenance attestation names the expected repository. Security teams should fold this into broader DevSecOps practices, since dependency trust failures rarely stay contained to one package. Teams running GitLab’s Trusted Publishing integration should apply the same scrutiny, since Bloom found it shares the underlying flaw.
Key Takeaways
- SlugFest let attackers publish malicious npm package updates without stealing any credentials.
- Bloom Security traced SlugFest to roughly 1,500 npm packages with over 10 million downloads combined.
- GitHub shipped a fix on October 2, 2026, four months after Bloom’s initial report.
- Unvalidated Trusted Publishing configurations now expire within 48 hours of creation.
- AI coding agents install dozens of packages a month with little human review, raising the risk.
Frequently Asked Questions About the npm Trusted Publishing Vulnerability
What Does SlugFest Actually Exploit?
SlugFest exploits how npm validated Trusted Publishing relationships. npm checked a GitHub repository’s owner and name instead of its permanent numeric ID. A renamed or deleted repo’s old name then became claimable.
Which npm Packages Were Affected?
Bloom Security’s scan flagged more than 1,500 packages as potentially exposed, among them tools for scanning, authentication, and cryptography. The firm has not published the specific package names.
Has Anyone Exploited SlugFest in the Wild?
Bloom says it has not observed active exploitation. The firm demonstrated the attack only against its own test package during research.
Does GitHub’s Fix Protect Configurations Set Up Before October 2026?
GitHub has not said whether trust relationships bound before the fix were retroactively affected. Maintainers should still audit older configurations rather than assume they are safe.
Is GitLab’s Trusted Publishing Integration Also Vulnerable?
Yes. Bloom Security says npm’s GitLab Trusted Publishing integration shares the same underlying weakness as the GitHub integration.
How Can I Check if My Package Is Exposed?
Open your package settings on npmjs.com and review each entry under Trusted Publishing. Confirm every linked repository still belongs to your account, and recreate any binding tied to a renamed or deleted repo.
Final Thoughts
SlugFest reminds us that supply chain security depends on details most teams never check, like whether a linked repository still belongs to its original owner. The fix itself is simple: a 48-hour validation window closes the gap GitHub left open since July 2025. What matters more is the habit behind it. Audit your Trusted Publishing bindings today. Verify provenance attestations before trusting an update, and apply the same scrutiny to GitLab integrations.
Photo by Burst: Unsplash
