npm Trusted Publishing 'SlugFest' flaw: a freed GitHub repository name could be re-registered to publish new versions of someone else's package — Bloom Security counted 1,500+ exposed packages (10M+ downloads); GitHub fixed it on 2 Oct with a 48-hour expiry on unvalidated bindings
Bloom Security disclosed 'SlugFest' on 13 October 2026, a takeover path in npm Trusted Publishing, the OpenID Connect (OIDC) feature that lets a GitHub Actions workflow swap a short-lived identity token for an npm publishing credential instead of storing a long-lived token. Until a binding completed its first successful publish, npm recorded the trusted repository only by its human-readable owner/repo name (the 'slug'), not by GitHub's permanent repository and owner IDs. If the maintainer then renamed, transferred or deleted that repository, or the owner account was renamed or deleted, anyone could create a repository at the freed name, add a workflow file with the expected filename, and receive a valid publish credential for a package they did not own. No stolen token or account access is needed, and a release pushed this way carries a valid Sigstore provenance attestation, naming the attacker's repository. Bloom's scan found more than 1,500 vulnerable packages with over 10 million total downloads and more than a million a month. It is not publishing the list. It ran the attack end to end only against packages and repositories it controlled, and says it is unknown whether anyone abused the flaw in the wild. Bloom says npm's GitLab trusted publishing integration had the same weakness. Bloom reported the issue through GitHub's HackerOne programme on 6 June; GitHub validated it on 9 June, and Bloom says follow-ups after 8 July went unanswered until it found the fix when it checked again before publishing. GitHub's changelog of 2 October 2026 says unvalidated npm trusted publishing configurations now expire 48 hours after creation and can no longer authorise publishing, and that npm now rejects trusted publishing tokens from GitHub Actions issue_comment events, alongside the existing pull_request_target block. GitHub told Help Net Security it shipped fixes after validating the bug bounty report; its statement does not say whether older bindings were re-bound to permanent IDs. Bloom's broader point is that AI coding agents now pull in about 70 packages a month on a typical endpoint (close to 350 on developer machines), usually without review, so a hijacked package can spread without fooling a human. Primary: Bloom Security; vendor: GitHub changelog; wire: Help Net Security and Cyber Security News (13 Oct).
- Product
- npm registry Trusted Publishing (OIDC publishing from GitHub Actions; GitLab CI/CD integration also affected per Bloom)
- Versions
- Registry-side issue: trusted publisher bindings that had not yet completed a first successful publish, before GitHub's 2 Oct 2026 change. Bindings that had published were tied to immutable repository IDs.
- Exploited in Australia?
- unknown
- Patch to
- Fixed on the registry side by GitHub on 2 Oct 2026 (unvalidated bindings expire after 48 hours; issue_comment-triggered tokens rejected); no client update needed. Maintainers: run npm trust list for every package and confirm each repository still belongs to you; delete and re-create bindings after any repository rename or transfer, and remove the binding before deleting a repository; move publishing workflows to push, release or workflow_dispatch events. Consumers: check that a package's provenance attestation names the repository the project should come from, pin versions, and block install scripts (npm --ignore-scripts) on build hosts and machines where AI agents install packages.
Primary: Bloom Security — SlugFest: millions of AI agents download exposed npm packages (13 Oct 2026) · Vendor: GitHub changelog — Unvalidated npm trusted publishing configurations now expire (2 Oct 2026) · Help Net Security — npm Trusted Publishing flaw exposed 1,500+ npm packages to takeover (13 Oct 2026; GitHub statement)