Security Digest · Oct 13, 2026 · Vulnerability · CI/CD
SlugFest: npm Trusted Publishing Repo-Name Hijack
npm matched trusted publishers by repo name, so 1,500+ packages could be published from a reclaimed slug. Fixed by npm Oct 2, 2026; audit your bindings.
Our verdict
Most can relax
The hole was closed on npm's side on October 2, 2026 and no abuse has been reported, so most teams have nothing to patch; maintainers should still spend five minutes auditing trusted publisher bindings and recent publishes.
Who must act: npm package maintainers who created trusted publisher configurations that never completed a publish, renamed, transferred or deleted a bound repository or GitHub owner, or publish from GitHub Actions issue_comment workflows.
Who can relax: Package consumers and maintainers whose trusted publisher bindings have already published successfully from a repository they still control; npm binds those to the repository's immutable identity.
- Affected
- npm trusted publisher configurations (GitHub Actions and GitLab) that had not yet completed a first publish, before npm's Oct 2, 2026 change
More than 1,500 packages with such bindings pointing at claimable repository slugs (per Bloom Security) - Fixed in
- npm registry change of Oct 2, 2026: unvalidated trusted publishing configurations expire 48 hours after creation
npm now rejects trusted publishing tokens from GitHub Actions issue_comment events (in addition to pull_request_target) - CVSS
- Not scored
- EPSS
- n/a
- CISA KEV
- Not listed
- Exploitation
- No known exploitation
- Severity
- High
What to do
- Run npm trust list <package> (npm 11.15.0 or later) for each package you maintain and confirm every bound repository slug still belongs to you.
- Delete and re-create bindings after any repository or owner rename, transfer or deletion; remove a binding before deleting its repository.
- Publish once from a newly created binding within 48 hours so it is validated against the repository's immutable identity, or it will expire.
- Move any publish workflow triggered by issue_comment to push, release or workflow_dispatch.
- Review npm publish history and alerts for versions you did not release, especially on packages whose bindings were never used before October 2, 2026.
How to check if you are affected or compromised
- npm trust list <package> --json and check each repository slug with gh api repos/<owner>/<repo> to confirm it resolves to a repository you control.
- npm view <package> time --json to list publish timestamps, and compare against your own release runs.
- Look for packages whose trusted publisher binding existed for a long time without a publish, which was the precondition for the attack.
What happened#
npm trusted publishing lets a CI workflow publish a package with a short-lived OIDC token instead of a stored npm token. On October 13, 2026, Bloom Security published SlugFest, research showing how npm decided which repository was trusted. Until a binding's first successful publish, npm matched on the repository slug (owner/repo) and workflow filename. It ignored the permanent repository_id and repository_owner_id claims that GitHub puts in the token. If a maintainer renamed, transferred or deleted the bound repository or owner, anyone could create a repository at the freed slug, add a workflow with the same filename and id-token: write, and exchange the resulting token for "a valid, time-limited publish token for a package they do not own." No credentials had to be stolen. Bloom says the same issue affected npm's GitLab trusted publishing.
Bloom counted more than 1,500 vulnerable packages with over 10 million total downloads. It reported the flaw through GitHub's HackerOne program on June 6, 2026. GitHub fixed it about four months later in a changelog entry dated October 2: unvalidated trusted publishing configurations now expire 48 hours after creation, and a configuration "becomes validated and exempt from expiry after its first successful publish." The same change makes npm reject trusted publishing tokens minted by GitHub Actions issue_comment events, alongside the existing pull_request_target block. No CVE was assigned.
Who is affected#
The precondition was narrow: a trusted publisher binding that had never been used to publish, pointing at a slug someone else could claim. That covers bindings set up "for later," or set up before a repository move, and repositories that were deleted or renamed afterwards. Bloom withheld its list of affected packages because the pattern is still common. Package consumers were exposed only if an attacker actually published a version that way. Neither Bloom nor GitHub has reported that happening as of October 21, 2026. Bloom does say it blocked customers' AI coding agents that tried to download some of the vulnerable packages, a reminder that agents that auto-install the latest versions would pick up a hijacked release quickly.
Do you really need to act?#
Consumers: no. The fix is on the registry side, and there is nothing to upgrade. Maintainers: a short audit is worthwhile. npm's documentation now says a new configuration "must complete its first successful publish within 2 days," after which it is bound "to the repository's immutable identity." Bindings that already published were bound that way before the fix, so the gap is closed for them. What remains is housekeeping. Expired configurations stay visible but no longer authorize publishing, so recreate any you still need. Any release workflow triggered by issue_comment will now fail and needs a different trigger.
What to do now#
- Update npm to 11.15.0 or later and run
npm trust list <package>for each package you maintain (see npm trust). - For each binding, confirm the slug still resolves to your repository:
gh api repos/<owner>/<repo> --jq '.id,.owner.login'. - Remove stale bindings with
npm trust revoke <package> --id=<trust-id>, and re-create them after any rename or transfer. Revoke a binding before deleting its repository. - After creating a binding, publish within 48 hours so it validates.
- Move publish jobs off
issue_commenttopush,releaseorworkflow_dispatch.
How to tell if you were hit#
Compare the registry's publish history, npm view <package> time --json, against your own release runs. A version you did not ship from your repository is the signal. Pay particular attention to packages whose trusted publisher binding existed for weeks without a publish before October 2, 2026, and to bindings whose slug now points to a repository with an ID you do not recognize. If you find an unexplained version, deprecate it, contact npm support and revoke the binding. The Hacker News summarizes the same maintainer checks.
Timeline#
- — Bloom Security reports the flaw to GitHub via HackerOne.
- — The report is triaged and validated.
- — GitHub's last response before the fix, per Bloom.
- — GitHub ships 48-hour expiry for unvalidated configurations and blocks
issue_commenttokens. - — Bloom publishes SlugFest, followed by press coverage.
Sources
Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.
Original and primary sources
- GitHub Changelog — Unvalidated npm trusted publishing configurations now expire (Oct 2, 2026) github.blog
- npm Docs — Trusted publishing for npm packages docs.npmjs.com
- npm Docs — npm trust docs.npmjs.com
- Bloom Security — SlugFest: millions of AI agents download exposed npm packages bloom.security