GITHUB has tightened npm trusted publishing after researchers exposed a weakness that could let attackers hijack packages without credential theft. The changes, announced 48 hours after a trusted publishing configuration is created, mean unvalidated configurations now expire if they have not completed a first publish. If the repository or project identity changes, a fresh 48‑hour validation window is required, and ordinary edits won’t reset the countdown.
GitHub warns that trusting a renamed or transferred repository carries risk, and npm will also reject trusted publishing tokens coming from GitHub Actions issue_comment events, in addition to the existing pull_request_target restriction.
Bloom Security’s findings underlie the fix: the attack, nicknamed SlugFest, exploited how npm trusts a repository slug (owner/repo name) rather than an immutable repository ID. If the slug becomes available after renames or deletions, an attacker can create a new repo at that slug, mint an OIDC token tied to the reclaimed slug, and push a malicious version under a legitimate package name. In tests, Bloom observed more than 1,500 vulnerable packages and over 10 million downloads tied to the exposed trust.
Practically, developers should audit trusted publisher bindings, delete and rebind trusts when repositories are renamed or transferred, monitor for unexpected npm publish events, and remove trust bindings whenever a repository is deleted or moved. The incident highlights how the human-readable slug remains a critical, mutable invariant in supply chain trust.