---
title: "SlugFest: npm Trusted Publishing Repo-Name Hijack"
url: https://erroneo.us/security/briefs/slugfest-npm-trusted-publishing-slug-hijack/
description: "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."
type: security-brief
section: "Security Digest"
date_published: 2026-10-13
date_modified: 2026-10-21
publisher: erroneo.us
author: erroneo.us Security Desk
verdict: "Most can relax"
cves: []
severity: "high"
exploited: "none-known"
kev: false
license: All rights reserved. Quote with attribution and a link.
---

# SlugFest: npm Trusted Publishing Repo-Name Hijack

**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:** 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)
- **CVEs:** none
- **CISA KEV:** no · **Exploitation:** No known exploitation

## What to do

1. 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.
2. Delete and re-create bindings after any repository or owner rename, transfer or deletion; remove a binding before deleting its repository.
3. Publish once from a newly created binding within 48 hours so it is validated against the repository's immutable identity, or it will expire.
4. Move any publish workflow triggered by issue_comment to push, release or workflow_dispatch.
5. 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

- 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](https://bloom.security/blog/slugfest-millions-of-ai-agents-download-exposed-npm-packages), 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](https://github.blog/changelog/2026-10-02-unvalidated-npm-trusted-publishing-configurations-now-expire/): 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](https://docs.npmjs.com/trusted-publishers) 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

1. Update npm to 11.15.0 or later and run `npm trust list <package>` for each package you maintain (see [npm trust](https://docs.npmjs.com/cli/v11/commands/npm-trust/)).
2. For each binding, confirm the slug still resolves to your repository: `gh api repos/<owner>/<repo> --jq '.id,.owner.login'`.
3. 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.
4. After creating a binding, publish within 48 hours so it validates.
5. Move publish jobs off `issue_comment` to `push`, `release` or `workflow_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](https://thehackernews.com/2026/10/github-tightens-npm-publishing-after.html) summarizes the same maintainer checks.

## Timeline

- Jun 6, 2026 — Bloom Security reports the flaw to GitHub via HackerOne.
- Jun 9, 2026 — The report is triaged and validated.
- Jul 8, 2026 — GitHub's last response before the fix, per Bloom.
- Oct 2, 2026 — GitHub ships 48-hour expiry for unvalidated configurations and blocks `issue_comment` tokens.
- Oct 13, 2026 — Bloom publishes SlugFest, followed by press coverage.

## Sources

1. [GitHub Changelog — Unvalidated npm trusted publishing configurations now expire (Oct 2, 2026)](https://github.blog/changelog/2026-10-02-unvalidated-npm-trusted-publishing-configurations-now-expire/)
2. [npm Docs — Trusted publishing for npm packages](https://docs.npmjs.com/trusted-publishers)
3. [npm Docs — npm trust](https://docs.npmjs.com/cli/v11/commands/npm-trust/)
4. [Bloom Security — SlugFest: millions of AI agents download exposed npm packages](https://bloom.security/blog/slugfest-millions-of-ai-agents-download-exposed-npm-packages)
5. [The Hacker News — GitHub tightens npm publishing after flaw left 1,500+ packages vulnerable to hijacking](https://thehackernews.com/2026/10/github-tightens-npm-publishing-after.html)

---
Source page: https://erroneo.us/security/briefs/slugfest-npm-trusted-publishing-slug-hijack/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt