Bloom Security researchers found that npm's Trusted Publishing feature let an attacker push new versions of someone else's package without stealing a single credential.

The flaw, codenamed SlugFest, required only that an attacker register a GitHub repository name — a slug — that a maintainer had left behind through a rename, transfer, or deletion.

Bloom counted more than 1,500 exposed npm packages with over 10 million combined downloads and more than a million downloads per month, including security scanners, authentication tools, and cryptographic packages, according to CSO Online.

Trusted Publishing, generally available on npm since July 2025, replaces long-lived tokens with short-lived OpenID Connect credentials issued to a GitHub Actions workflow.

The problem was identification: before a repository's first successful publish, npm stored the human-readable owner/repository slug rather than the permanent numeric ID GitHub assigns and includes in every OIDC token.

Security researcher Golan Myers compared it to 'a lock that checks the address on the door rather than who owns the house: when the owner moves out, whoever moves in gets the key.'

The Hacker News reports npm ignored the immutable IDs until first publication, so anyone claiming the freed slug could mint a valid publishing token.

The demonstration was end-to-end. Bloom published a new version of a researcher-controlled npm package from a second repository belonging to a different organization — the only shared element was the reclaimed slug, per Help Net Security.

Worse, the release still carried a valid provenance attestation, a signed build record naming the attacker's repository.

Help Net Security notes that verification systems checking only that an attestation exists, without confirming its source matches the expected maintainer repository, would not flag the discrepancy. Bloom says npm's GitLab Trusted Publishing integration shares the same weakness.

Bloom argues AI coding agents make flaws like this reach further. Based on telemetry from dozens of organizations, it estimates agents on a typical endpoint install about 70 packages a month, rising to roughly 350 on developer machines — excluding transitive dependencies.

'Agents resolve dependencies on their own, tend to take the latest version, and rarely check where a package came from,' Bloom said, per The Hacker News.

Bloom reported catching and blocking a customer's AI agent attempting to install one of the affected packages, and Myers told CSO that 'a hijacked package doesn't need to find a developer anymore. It only needs to be the package an agent chooses.'

Bloom reported the vulnerability through GitHub's HackerOne bug bounty program on June 6, 2026; GitHub validated it on June 9. According to Help Net Security, the last reply came on July 8, and six follow-ups — including a mediation request — went unanswered before Bloom prepared to publish.

The fix shipped on October 2, introducing a 48-hour expiry for unvalidated Trusted Publishing configurations, which become validated and bound to the repository's immutable identity after their first successful publish. npm also rejects trusted publishing tokens from GitHub Actions issue_comment events, and a GitHub spokesperson apologized for the delayed communication, per The Next Web.

Bloom is not publishing the affected package names, so developers cannot check against a list, Help Net Security reports.

Maintainers are advised to run npm trust list and verify every configured repository address still resolves to a repository under their control, delete and recreate bindings after renames or transfers, remove trust configurations before deleting repositories, and monitor for unexpected publish events.

Enterprises are told to audit software beyond traditional packages — extensions, plugins, MCPs, and skills — and enforce supply-chain firewall controls.

Myers said there is no evidence of exploitation in the wild, but the only precondition was slug availability, 'entirely a function of the victim's own repository hygiene.'