Bloom Security said it found over 1,500 vulnerable packages that have been collectively downloaded more than 10 million times.
GitHub imposes a 48‑hour validation window for trusted publishing
In response to research that demonstrated a hijack path through npm's trusted publishing, GitHub — the Microsoft-owned subsidiary that operates the npm integration with GitHub Actions — now expires unvalidated trusted publishing configurations 48 hours after creation. "Your configuration becomes validated and exempt from expiry after its first successful publish," GitHub said in updated documentation, noting that "changing the repository or project identity requires a new trust relationship with a fresh 48‑hour validation window -- ordinary edits don't restart the deadline."
The documentation update also says npm will reject trusted publishing tokens originating from GitHub Actions issue_comment events going forward, and it removes the existing pull_request_target restriction. GitHub framed the change as a way to reduce the risk created when a repository or project name changes ownership: "The change contains the risk associated with trusting a repository or project name that changes ownership," the company said.
How the vulnerability — dubbed "SlugFest" — works
Trusted publishing was introduced in npm in July 2025 as a credential‑free authentication method that lets CI/CD systems, including GitHub Actions, push packages using OpenID Connect (OIDC) tokens. The model uses short‑lived tokens minted for specific workflow runs and verifies those tokens against a pre‑authorized configuration, avoiding long‑lived npm secrets and producing provenance attestations for published packages.
Bloom Security identified a problem in how npm bound that trust to a repository. According to security researcher Golan Myers, npm "records the repository's address, [...] instead of the permanent ID GitHub assigns it, at least until a version is first published from that repository." Put another way, the name-based slug — the human-readable "owner/repository" path — was trusted before npm checked the repository's immutable numeric ID.
- Create a repository at a freed slug (the "owner/repository" path), which causes GitHub to issue a fresh repository ID.
- Create and trigger an npm publish workflow, which mints an OIDC token carrying the reclaimed slug and the new numeric repository ID.
- Submit the token to the npm exchange endpoint. npm finds that the repository claim matches the stored slug and issues a publish credential.
- The attacker receives a time‑limited publish token for a package they do not own and pushes malicious changes to the registry.
Bloom Security labeled the technique SlugFest and warned it can be abused to publish malicious versions under legitimate package names, inheriting reputation, download counts and dependent relationships.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildScale of the exposure and AI agents as an accelerant
Bloom Security reported the findings to GitHub on June 6, 2026. The firm said it found more than 1,500 vulnerable packages with a combined download count exceeding 10 million. Myers highlighted how automation raises the stakes: "Imagine this: an attacker compromises a single package. An AI agent on a popular package maintainer's device autonomously pulls it for a project," he said. "That single endpoint is used to push malicious code to the popular package. All the package users are exposed. All because one person with the correct access was exposed."
Bloom Security also noted that agents "resolve dependencies on their own, tend to take the latest version, and rarely check where a package came from," meaning a malicious version published through a reclaimed slug can be pulled and executed with no human in the loop. The firm described the potential result as a Shai‑Hulud‑style cascading supply‑chain attack.
Developer guidance: audit, delete, recreate, monitor
Bloom Security included specific mitigation steps for npm package maintainers. The firm advised developers to:
- Audit trusted publisher bindings and verify if the listed repository slug still resolves to the repository under their control.
- If the repository has been renamed or transferred, delete the existing trust binding and re‑create it pointing at the current slug.
- Monitor for unexpected npm publish events.
- Delete trust bindings every time a repository is deleted, transferred, or renamed.
Myers framed the operational root cause succinctly: "The attack requires no insider knowledge, no credential theft, and no race condition. The only precondition is slug availability (on a binding that has not yet been used to publish), which is entirely a function of the victim's own repository hygiene." He added a broader point about trust systems: "What this research demonstrates is something the security community has seen repeatedly across supply chain attacks: the binding between a human-readable identifier and the thing it identifies is the most important invariant in any trust system."
Related discovery: extension namespace reuse in marketplaces
Bloom Security's SlugFest disclosure followed earlier August findings from the same firm that exposed a different namespace‑reclamation risk in extension marketplaces. The technique, dubbed Extension Resurrection, showed that Open VSX and Microsoft's VS Code Marketplace allowed extension packs to reference non‑existent extensions that an attacker could claim. Bloom flagged 87 vulnerable packs in Open VSX and 677 in the VS Code Marketplace, noting attackers could claim empty slots and publish malicious code that would be installed automatically alongside trusted packs.
GitHub's 48‑hour validation window and the token restrictions represent concrete fixes to the specific path Bloom Security described. The firm's advice — audit bindings, delete trust after repo moves, and monitor unexpected publishes — remains the immediate operational response for maintainers whose trusted‑publisher bindings predate a first successful publish.
https://thehackernews.com/2026/10/github-tightens-npm-publishing-after.html
