A flaw in npm trusted publishing, codenamed SlugFest, left more than 1,500 packages open to hijacking by anyone who could claim an abandoned GitHub repository name. GitHub announced tighter rules on October 13, and the source reports no confirmed abuse.
SlugFest: Trusted Publishing Tracked a Repository Name Instead of Its ID
Researcher Golan Myers of Bloom Security found that npm’s trusted publishing, which uses GitHub Actions OIDC, recorded a repository’s name in the “owner/repo” form instead of its immutable GitHub ID until the first successful publish. Names can change hands, and IDs cannot.
If a maintainer renamed, transferred or deleted a repository, an attacker could claim the abandoned name and publish new malicious versions of the victim package. The attack requires no stolen credentials.
What an Attacker Inherits
A hijacked package carries its name, reputation, download counts and dependents. Bloom Security warned of cascading supply-chain attacks of the Shai-Hulud kind. It said the risk grows when AI agents resolve and pull the latest versions of packages automatically.
GitHub’s New Rules Expire Unvalidated Configurations After 48 Hours
GitHub responded by expiring unvalidated trusted-publishing configurations 48 hours after creation. A configuration becomes validated, and exempt from the expiry, after its first successful publish. Changing the repository or project identity starts a new 48-hour window.
The change targets the window between configuration and first publish. Until a package publishes successfully through trusted publishing, its configuration is unvalidated and now lapses after 48 hours, so a stale entry no longer sits waiting indefinitely for a claimant to take over the name.
Added Restriction on issue_comment Events
npm now also rejects trusted-publishing tokens from GitHub Actions issue_comment events. That adds to an existing restriction on pull_request_target events.
Timeline From Report to Mitigation
Trusted publishing was introduced in July 2025. Bloom Security reported the flaw to GitHub on June 6, and GitHub announced its mitigation on October 13, a gap of about four months.
Scale of Exposure
The headline figure is more than 1,500 vulnerable packages. The source does not report confirmed abuse, and it does not say how the 1,500 figure was calculated or how many of those packages have since been protected by the new rules.
The structure of the flaw is what makes it notable. Trusted publishing was designed to remove long-lived tokens from the publishing process, and the mechanism is meant to reduce theft risk. SlugFest shows that the identity check at the center of that design depended on a value that could be reclaimed. An attacker who exploited it would have appeared to the registry as the legitimate publisher, which is a different outcome from stealing a token that defenders can later revoke.
GitHub’s fix sets a deadline: a configuration that has not completed a publish within 48 hours expires, which shrinks the period in which an abandoned or newly changed name can be claimed.
June 6 Report, October 13 Fix
Bloom Security reported SlugFest to GitHub on June 6, and the mitigation came on October 13. The source does not describe what happened in between, whether the 1,500 packages were reachable throughout that period, or whether anyone besides Bloom found the flaw. It also does not say how many of the affected packages have a maintainer who renamed or deleted a repository, which is the condition an attacker needs.
The Shai-Hulud comparison in Bloom’s warning points to earlier cascading npm attacks, where one compromised package spreads to the packages that depend on it. The added mention of AI agents describes a faster route for a malicious version to reach builds, since an agent that pulls the latest version automatically needs no human decision to install the hijacked release.
