Bloom Security disclosed SlugFest on 13 October 2026. npm's Trusted Publishing feature recorded the allowed GitHub repository by its owner/repo name, the slug, and did not check GitHub's permanent numeric repository and owner IDs. After a rename, transfer, or deletion, anyone who registered the old name could add a matching workflow file and receive a short-lived publish credential for a package they did not own.

What happened

Trusted Publishing has been generally available since July 2025. It was meant to replace long-lived npm tokens: a GitHub Actions workflow gets a signed identity token, and npm swaps it for a credential that expires in minutes. The binding was the weak part. Bloom ran the attack end to end on infrastructure it controlled, including a second organization that claimed a freed slug. A release published that way can also carry a valid provenance attestation that names the attacker's repository.

Bloom's registry scan found more than 1,500 exposed packages, with more than 10 million downloads in total and more than 1 million a month. The set includes security scanners, authentication tools, and cryptographic packages. Bloom is not publishing the package names. GitHub, which owns npm, told Help Net Security it learned of the report through its bug bounty program and shipped a fix. Unvalidated Trusted Publishing configurations now expire 48 hours after creation and can no longer authorize publishing. GitHub announced that change on 2 October. Bloom reported the issue on 6 June, and GitHub validated it on 9 June.

Bloom says it has not seen exploitation in the wild. GitHub has not said whether configurations that already published before the change were retroactively bound to immutable repository IDs. Bloom also says npm's GitLab trusted-publishing integration has the same class of weakness.

Who is affected

• Maintainers who configured Trusted Publishing and later renamed, transferred, or deleted the bound repository or owner
• Anyone installing those packages, including CI and AI coding agents that pull dependencies without a human review
• Organizations that treat a provenance attestation as proof of the intended repository

GitHub retires names of repositories with more than 100 clones in the week before an owner account is renamed or deleted. That protection does not cover every abandoned slug. Bloom says it only counted claimable names.

What to do now

If you maintain a package with Trusted Publishing, run npm trust list and confirm every listed repository still resolves to one you control. Delete and recreate any binding that points at a renamed or transferred repository. Remove the binding before you delete a repository. Do not leave an unvalidated configuration sitting around: new ones die in 48 hours, old ones may not.

Consumers cannot check a public package list, because Bloom withheld the names. Verify that a package's provenance attestation names the repository the project actually uses. Pin versions in production builds, and treat unexpected provenance repository names as a stop-ship signal. AI coding agents that install packages on their own should be denied write access to production registries until this review is done.

Source: Help Net Security, npm Trusted Publishing flaw exposed 1,500+ npm packages to takeover.

Also on the blog

• CVE-2026-104935: Ivanti Connect Secure auth bypass exploited since Oct 3
• CVE-2026-96951: Windows Shell MOTW bypass exploited, patch by 16 Oct
• GitLab CVE-2026-97229: CVSS 10.0 unauthenticated RCE
• CVE-2026-105445: Docker Hub PAT reassigned to another user

Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.