npm Trusted Publishing Let Anyone Claim a Renamed GitHub Slug and Publish, and the Fix Is a 48-Hour Expiry

An attacker who can claim a GitHub repository name that an npm package still trusts can publish that package without stealing a single credential, provided the repository never completed a first publish. Bloom Security calls the technique SlugFest, says it affected more than 1,500 packages, and published its write-up on Oct. 13, eleven days after GitHub changed how npm validates the binding.

The fix is in place. If you maintain an npm package with trusted publishing, run npm trust list and confirm every slug still points at a repository you control.

How a slug becomes a publish credential

npm trusted publishing links a package to a GitHub repository by its owner-and-name slug, a workflow filename and an optional environment. Bloom's account says npm did not store the repository's permanent numeric ID until the first successful publish from it.

If a bound repository or its owner account is renamed, transferred or deleted before that first publish, the old slug can be registered by someone else. That person creates a workflow with the same filename, obtains a valid OIDC token from GitHub and exchanges it for an npm publish credential. Bloom says it tested the chain end to end against an npm scope it owned, publishing from a repository in a second organisation.

The preconditions are narrow: a trusted publisher pointing at a claimable slug, and a repository that had never published. No maintainer secret is involved.

What GitHub changed on Oct. 2

GitHub's changelog says unvalidated configurations now expire "48 hours after creation" and can no longer authorize publishing. A configuration counts as validated after its first successful publish. Changing the repository or project identity needs a new trust relationship and a fresh 48-hour window, while ordinary edits do not restart the clock.

npm also now rejects trusted publishing tokens from GitHub Actions issue_comment events, joining an existing restriction on pull_request_target. Workflows that publish from those events should move to push, release or workflow_dispatch.

Bloom had proposed resolving and storing the immutable repository and owner IDs when trust is created, as PyPI does. GitHub chose expiry instead, which narrows the window to 48 hours rather than closing it. Bloom adds that the issue also affected npm's GitLab trusted publishing.

The disclosure timeline

Date	Event
June 6, 2026	Reported through GitHub's HackerOne program
June 9, 2026	Triaged and validated
July 8, 2026	Last team response: "working on fixing the issue and determining its risk and severity"
Oct. 2, 2026	GitHub changelog announces the 48-hour expiry
Oct. 13, 2026	Bloom publishes

Counting from June 6 to Oct. 2 gives 118 days; Bloom's own figure is "over 120 days" from disclosure to fix. Bloom says six follow-ups, including a mediation request to HackerOne, went unanswered, and that the npm team later apologised for the lack of communication. Golan Myers is the only person Bloom names as an author; GitHub names no one in the changelog.

How big the exposure is

Bloom's scan covered packages that have trusted publishing configured, then checked whether their repositories and owners were claimable. It found more than 1,500 packages with over 10 million total downloads. The write-up presents its download figures in a way that The Hacker News also reports as ambiguous, so treat 10 million as an order of magnitude, not an audited total.

Neither the changelog nor the Bloom write-up, as read for this report, describes a package actually taken over this way. Bloom's argument is about AI coding agents, which it says resolve dependencies automatically, often take the latest version and rarely check origin. It estimates an average endpoint installs about 70 agent-selected packages a month and a developer machine about 350, both Bloom's own figures.

This is the second registry-binding problem Bloom has reported since August, when it flagged 87 extension packs in Open VSX and 677 in the VS Code Marketplace. For another dependency-chain failure that surfaced through a maintainer's public complaint, see the Gentoo developer's plea about uv-build.

What maintainers should do now

Run npm trust list for each package. After renaming or transferring a bound repository, delete the binding and recreate it at the new slug. Remove the binding before deleting a repository unless you plan to recreate it at the same name. Publish a version immediately after creating a new binding, and watch for publish events you did not start.

For a hardware counterpart, where a trusted channel carried a tampered product, see the Ledger Nano X implant report.

The next test is whether GitHub stores repository IDs at creation, which neither source says it plans to do.