An npm security loophole dubbed “SlugFest” has left over 1,500 packages vulnerable to takeover after GitHub repository names are abandoned and later reclaimed. These packages total more than 10 million downloads, with over a million installs monthly — making the risk significant for developers, CI/CD systems, and organizations depending on npm dependencies.
How SlugFest Opens the Door
npm’s Trusted Publishing feature was designed to secure package releases by replacing permanent tokens with short-lived credentials issued via OpenID Connect (OIDC), so maintainers don’t need to store long-lived secrets in workflows. The issue starts before the first trusted release. When a package links to GitHub using only the human-friendly “slug” (e.g., organization/project), rather than GitHub’s immutable numeric repository ID, that setup remains vulnerable until the package completes its first Trusted Publishing operation.
If a GitHub repo slug becomes available — for example, due to renaming, deletion, or account takeover — an attacker can claim the slug, add appropriately named workflow files, request an OIDC token, and have npm issue valid publishing credentials for the legit-named package. The attacker gains control without ever stealing tokens, access to the npm account, or the original repo content.
AI Agents Amp Up the Threat
Bloom Security’s research shows AI coding agents on typical endpoints install around 70 npm packages each month, while developer workstation environments may pull in close to 350. These numbers exclude transitive dependencies, meaning many more packages may be impacted indirectly. Tools embedded in IDEs or bot agents often install and execute packages automatically, sometimes including lifecycle or install-time scripts — making it possible for malicious code published via SlugFest to run undetected.
Recent incidents have already demonstrated the dangers of trusted releases turning malicious. Valid provenance metadata may reveal where a package was built, but it doesn’t necessarily guarantee the integrity of the source repo or the build environment. That disconnect is what SlugFest exploits.
Mitigation, Fixes, and What Maintainers Should Do
The issue was reported via GitHub’s HackerOne program on June 6, 2026, verified on June 9, and patched on October 2. Changes include expiring unvalidated Trusted Publishing configurations if the initial trusted publish doesn’t occur within 48 hours. After a successful first publish, the binding switches to using GitHub’s immutable repository identity.
Also, tokens triggered by certain workflow events — like issue_comment and pull_request_target — are now blocked in Trusted Publishing, to reduce risk. Maintainers are advised to use safer triggers such as push, release, or workflow_dispatch.
Other recommended actions: review every Trusted Publishing configuration; confirm that all GitHub repos linked to npm packages are still under the maintainer’s control; remove and recreate bindings after repository renames, transfers, or deletions; monitor unexpected release activity; use version pinning where feasible; and scrutinize install scripts and provenance attestations.
SlugFest reveals a critical gap in supply-chain security: even systems built to reduce exposure can backfire when identity binding is based on mutable names. The exposure of more than 10 million downloads shows how much is at risk. The fixes implemented are strong steps — but vigilance will be essential moving forward. Keep an eye on this space, especially as CI/CD, AI agents, and Trusted Publishing evolve.
