A security research firm just published findings that should make any developer or security lead running npm packages uncomfortable. The research is called SlugFest, and it comes from Bloom Security.
What the Flaw Is
npm’s Trusted Publishing system is designed to replace long-lived secrets with short-lived credentials. A GitHub Actions workflow gets an OpenID Connect token from GitHub, exchanges it for a temporary npm publishing credential, and ships the package. No static secrets to leak.
The problem: npm originally established that trust relationship using the repository’s human-readable address (the slug), not its permanent identifier. When a repo is renamed, transferred, or deleted, that slug becomes available for anyone to claim. If the original Trusted Publisher binding still pointed to the old address and had never completed a successful publish, a different repository could satisfy the trust configuration and publish under the legitimate package name.
No stolen credentials required.
The Scale of the Problem
Bloom scanned the npm registry and found more than 1,500 packages vulnerable to this attack. Combined, those packages had accumulated over 10 million downloads and more than one million downloads per month. The researchers note these figures cover only the subset of npm packages configured for Trusted Publishing.

Why AI Agents Make This Worse
Bloom also measured AI-driven package installation across large enterprises. A typical endpoint receives around 70 packages installed by AI agents per month. Developer machines can approach 350. Individual agents install between 0.3 and 1.2 packages per day depending on type. Developer machines average two to three direct installations daily.
The average endpoint runs three agents across CLIs, IDEs, extensions, and assistants. Developer machines can run five or more. These numbers exclude transitive dependencies, so the real software footprint is larger.
Bloom reported catching and blocking a customer’s AI agent attempting to install one of the affected packages. When agents automatically resolve and install the latest available version of a package, a malicious release carrying a postinstall hook can execute code on developer machines or CI systems without any human reviewing the release history.
The research also flags a provenance verification blind spot: a malicious release can carry an attestation linked to the attacker’s own repository. Some systems only verify that an attestation exists, not whether its source matches the expected maintainer repository.
The Fix and the Timeline
Bloom reported the vulnerability through GitHub’s HackerOne program on June 6, 2026. GitHub triaged and validated it on June 9. The last response before the fix came on July 8. After six additional follow-ups and a mediation request, Bloom prepared to publish. Before publication, it ran the attack test again and found npm had already implemented a fix. npm confirmed the remediation and apologized for the communication delay.
Bloom’s proposed solution was to store immutable repository and owner identifiers at trust setup time, then verify the repository identifier in the OIDC token during publishing authorization. PyPI’s Warehouse already follows this approach. The flaw also affected npm’s GitLab Trusted Publishing implementation.
What to Check Now
If you maintain npm packages with Trusted Publishing configured, Bloom advises:
- Run
npm trust listand confirm every configured repository address still resolves to a repo you control. - Recreate trust bindings after any repository rename or transfer.
- Remove trust configurations tied to repositories you’ve deleted.
For security leaders, Bloom recommends auditing installed software beyond traditional packages, including extensions, plugins, MCPs, and skills, and enforcing a supply-chain firewall to control what enters enterprise environments.

