npm Trusted Publishing SlugFest flaw: audit your bindings now

Trusted Publishing was supposed to be the safe way to ship to npm: no long-lived tokens, just a GitHub Actions workflow that npm trusts. Bloom Security showed that npm trusted the wrong thing. The npm Trusted Publishing flaw, which Bloom calls SlugFest, bound packages to a repository's name instead of its permanent ID. Rename, transfer or delete the repo, and whoever claims the old name can publish your package. npm shipped a partial fix. Your existing bindings are still your problem.

What actually happened

Per Bloom's write-up, a Trusted Publishing binding matched on the GitHub owner/repo slug plus the workflow filename. GitHub's numeric repository and owner IDs were only recorded after the first successful publish. So if a bound repo was renamed, moved or deleted before that, an attacker could register the freed slug, add a workflow with the expected filename and get a valid publish token. No stolen credentials. The release even carried valid provenance.

Bloom counted more than 1,500 vulnerable packages with over 10 million combined downloads, per CSO Online. Bloom proved the attack only against its own test package and says it has seen no exploitation in the wild. It has not published the list of affected packages.

The timeline is the uncomfortable part. Bloom reported the bug to GitHub on June 6; GitHub validated it June 9. The fix landed October 2: a binding with no publish within 48 hours of creation now expires. npm also now rejects trusted-publishing tokens from issue_comment workflow events. Bloom notes the fix does not record numeric IDs at binding time, which is how PyPI does it. Bloom says npm's GitLab integration had the same flaw.

Why it matters for your business

Old bindings were not retro-fixed. The 48-hour expiry stops new orphaned bindings. It does nothing for a binding that already published and then had its repo renamed or transferred. That review is on you.

Agents widen the blast radius. Bloom measured about 70 agent-installed packages per endpoint per month, and about 350 on developer machines, direct installs only. Agents tend to take the latest version without a human looking. As Bloom's researcher put it, a hijacked package "only needs to be the package an agent chooses."

If you consume npm, the fix is upstream. You cannot audit someone else's bindings. You can refuse brand-new versions: lockfiles, npm ci, and a minimum release age in CI and agent sandboxes.

Sources: Bloom Security, CSO Online.