GitHub hardens npm trusted publishing after SlugFest flaw

GitHub has changed how npm's trusted publishing works after researchers showed the feature trusted a repository's owner/repository slug — a reusable name — rather than its permanent numeric ID, until the first successful publish. Bloom Security, which calls the attack SlugFest, says an attacker who claims an abandoned or renamed slug could obtain a publish token for the victim's package and push malicious versions under its name. Bloom counts over 1,500 vulnerable packages, downloaded more than 10 million times. No CVE has been assigned, and the attack is demonstrated research, not observed in the wild — but if you publish to npm via GitHub Actions, your trusted-publishing config needs a look.

The primary source is GitHub's changelog, Unvalidated npm trusted publishing configurations now expire; the research is reported by The Hacker News citing Bloom Security.

What the flaw was

npm's trusted publishing — generally available since July 2025 — lets a package authorize a GitHub Actions workflow to publish without a long-lived token, by trusting an OIDC claim tied to the source repo. The gap: before a configuration's first successful publish, npm identified the trusted repo by its slug, which is not permanent. Rename or abandon a repo and the slug frees up. Whoever re-registers that owner/repository name could stand up a workflow, satisfy the slug-based trust, and mint a publish token for the original package.

What GitHub changed

Per the changelog, trusted publishing now behaves as follows (quoted):

• "Unvalidated npm trusted publishing configurations now expire 48 hours after creation."
• "Your configuration becomes validated and exempt from expiry after its first successful publish."
• "Changing the repository or project identity requires a new trust relationship with a fresh 48-hour validation window."
• "npm also now rejects trusted publishing tokens from GitHub Actions issue_comment events" — on top of the existing pull_request_target restriction.

In short: an unused trust config is no longer a standing liability, and identity changes force re-validation rather than silently riding the old slug.

Timeline

Bloom Security reported the issue to GitHub on June 6, 2026; GitHub's changelog is dated October 2, 2026. Trusted publishing reached general availability on npm in July 2025.

Action checklist

1. Audit your trusted-publishing configs for every npm package you own. Delete any that no longer map to a live, correctly named repository.
2. Publish once to validate any legitimate config you intend to keep — an unvalidated config now expires in 48 hours.
3. Reconcile package → repo ownership. If you renamed or archived a repo that a published package trusted, re-create the trust against the current identity rather than leaving a reclaimable slug.
4. Restrict publish-capable workflows to trusted events; the issue_comment and pull_request_target triggers are exactly the ones an outside contributor can reach.

Context

SlugFest is the latest in a steady run of npm supply-chain weaknesses we've tracked — from the Mastra/easy-day.js account takeover to typosquats sweeping cloud secrets and the GhostAction campaign against GitHub Actions. The pattern is consistent: the registry's trust anchor keeps turning out to be a mutable name — a package, an account, a repo slug — rather than an immutable identity. Trusting the numeric repo ID from the start, as GitHub now effectively requires post-validation, is the kind of fix that should have been the default when the feature shipped.