Analysis: This is a straight-news story with analysis of what it means for developers shipping JavaScript this week.
npm SlugFest: a repo rename was enough to hijack 1,500 packages
A flaw in npm’s Trusted Publishing system let attackers silently take over legitimate packages by claiming abandoned GitHub repository names. Bloom Security’s Golan Myers found that npm tied its publishing trust to a repository’s human-readable name rather than GitHub’s permanent numeric ID, and only recorded the numeric ID after the first successful publish. More than 1,500 packages with over 10 million combined downloads were exposed. The flaw, codenamed SlugFest, stayed exploitable for roughly four months after it was reported.
The attack required no stolen credentials. If a maintainer renamed, transferred, or deleted their repository before its first publish, the old name became claimable. An attacker could register it, add a workflow file matching the trusted configuration, and receive a valid publishing credential for a package they didn’t own. Bloom demonstrated it end to end on researcher-controlled repositories.
What makes this worse than a typical takeover: a release published this way carries a valid Sigstore provenance attestation, a signed build record, naming the attacker’s repository. Any tooling that only checks whether a signature exists, rather than which repository it names, would treat the malicious release as legitimate.
The AI agent angle is the real story
Bloom’s research argues the flaw lands harder because of how software gets installed now. Across dozens of organizations, the company measured AI coding agents installing roughly 70 packages per endpoint each month, approaching 350 on developer machines, usually without human review. As Myers put it, agents resolve dependencies on their own, take the latest version, and rarely check where a package came from. A malicious version published through a reclaimed name gets pulled in and runs with no human in the loop.
Bloom reported catching and blocking one customer’s AI agent attempting to install a package vulnerable to the issue. That’s not proof of exploitation, but it shows the exposure isn’t theoretical either.
Some scale context, because 1,500 packages sounds enormous on its own: Trusted Publishing only went generally available in July 2025, and adoption is still estimated under 20% of the registry. The denominator is small. This is a flaw in a young feature, not a rot through the whole ecosystem.
Three months of silence
Myers reported SlugFest through GitHub’s HackerOne bug bounty on June 6, 2026. GitHub validated it on June 9. The last substantive reply came July 8. After that, six follow-ups went unanswered, including a mediation request to HackerOne itself. The fix shipped October 2, and Bloom published its write-up October 13.
The fix is sensible: trusted publisher configurations that haven’t been validated now expire 48 hours after creation, and GitHub stopped issuing tokens for the issue_comment event. What GitHub hasn’t said is whether configurations that published before the change were bound to the immutable ID retroactively. That gap is worth watching.
The part that bothers me: four months from report to patch for a flaw in a publishing trust system, with most of that time silent. GitHub told Help Net Security it “worked to validate the report and ship fixes,” which is true and also not an explanation for the quiet stretch.
How do I check if my npm package is affected by SlugFest?
Run npm trust list and inspect every trusted publisher binding on your packages. If any linked GitHub repository was renamed, transferred, or deleted before its first publish, delete that binding and create a fresh one, then publish a version immediately so the binding gets anchored to the repository’s immutable ID with no window left open.
- Run npm trust list on every package you maintain and confirm each bound repository still resolves to one you control.
- Delete any binding whose repository was renamed, transferred, or deleted before its first publish, then re-create it.
- Publish a version immediately after creating a new binding so the 48-hour expiry window never matters.
- Monitor your publish history for releases you did not authorize, and check that provenance attestations name your repository.
If you find a publish you can’t explain, rotate every token, review your GitHub account activity, and notify downstream users. A hijacked package is a breach of everyone who installed it, which is why our data breach guide applies here too.
PyPI got this right years ago
PyPI, Python’s package registry, stores the immutable numeric ID when you set up Trusted Publishing. It never trusted the human-readable name. npm had a working example and didn’t copy it. The same weakness also showed up in npm’s GitLab integration, which points to a design assumption rather than a one-off bug.
As Myers writes in the disclosure: “It is like a lock that checks the address on the door rather than who owns the house: when the owner moves out, whoever moves in gets the key.”
Nobody can say whether SlugFest was exploited before October 2. Bloom made no such claim, and the flaw’s design means a successful attack would look exactly like a legitimate publish. Audit your bindings anyway.
