Bloom Security's SlugFest Research Says Over 1,500 npm Packages Were Open to Hijacking via Trusted Publishing; GitHub Now Expires Unvalidated Configs

Overview

Researchers at Bloom Security found that npm’s trusted publishing feature could let an attacker push a new version of someone else’s package without stealing any credentials, according to The Hacker News. The company said it found over 1,500 vulnerable packages that have been collectively downloaded more than 10 million times, and it codenamed the attack SlugFest. GitHub responded by expiring unvalidated trusted publishing configurations 48 hours after creation, a change it announced in a changelog entry dated October 2, 2026. The Hacker News reported the findings on October 13.

What We Know

How trusted publishing works. Per The Hacker News, trusted publishing was introduced in npm in July 2025 as a credential-free method that lets developers publish from a CI/CD platform such as GitHub Actions using OpenID Connect (OIDC) tokens. The registry verifies a short-lived token for a specific workflow run against a pre-authorized configuration, which removes the need to store, rotate or manually manage long-lived npm secrets.

The flaw. Bloom Security found that the registry identified the publishing repository by its slug, the “owner/repository” path, rather than by a permanent identifier. Security researcher Golan Myers explained, as quoted by The Hacker News: “It records the repository’s address, […] instead of the permanent ID GitHub assigns it, at least until a version is first published from that repository.” The outlet says the numeric repository IDs carried by GitHub’s OIDC tokens are completely ignored by npm until the first successful publish from that repository.

The attack path. According to The Hacker News, the only prerequisite is that the victim’s trusted publisher points to a GitHub slug an attacker can claim, and that the repository has never been used to publish a version of the package to npm. Once a maintainer renames, transfers or deletes a repository, an attacker can create a repository at the freed slug, which causes GitHub to issue a fresh repository ID. The attacker then triggers an npm publish workflow that mints an OIDC token carrying the reclaimed slug, submits the token to the npm exchange endpoint, and receives a time-limited publish token for a package they do not own. A malicious version published this way would sit under the legitimate package name while inheriting existing reputation, download counts and dependent relationships, the outlet writes.

Why AI agents raise the stakes. Bloom Security said: “Agents resolve dependencies on their own, tend to take the latest version, and rarely check where a package came from,” per The Hacker News. The outlet relays the company’s warning that a malicious version published through a reclaimed slug gets pulled in and runs with no human in the loop.

The fix. GitHub’s changelog entry says unvalidated npm trusted publishing configurations now expire 48 hours after creation and can no longer authorize publishing, which it says limits the risk of trusting a repository or project name that changes ownership. The Hacker News quotes GitHub as saying a configuration “becomes validated and exempt from expiry after its first successful publish,” while changing the repository or project identity requires a new trust relationship with a fresh 48-hour validation window. The same outlet says GitHub’s documentation now states that a new configuration must complete its first successful publish within two days, which binds it to the “repository’s immutable identity.” The Machine Herald covered the policy change itself previously; this article centers on the vulnerability behind it.

Timeline. The Hacker News says Bloom Security reported its findings to GitHub on June 6, 2026. The outlet adds that npm also now rejects trusted publishing tokens from GitHub Actions issue_comment events, in addition to the existing pull_request_target restriction.

Guidance for Maintainers

The Hacker News lists these recommended steps for npm package maintainers:

• Audit trusted publisher bindings and verify that the listed repository slug still resolves to a repository under the maintainer’s control.
• If a 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 is quoted by The Hacker News as saying: “The attack requires no insider knowledge, no credential theft, and no race condition.” In his words, the only precondition is slug availability on a binding not yet used to publish, “which is entirely a function of the victim’s own repository hygiene.”

Related Research

The Hacker News notes that this is not the first unconventional supply chain vector Bloom Security has reported. It says that in August the company found that both Open VSX and Microsoft’s VS Code Marketplace allowed extension packs to reference non-existent extensions, a technique called Extension Resurrection, and that as many as 87 packs in Open VSX and 677 packs in the VS Code Marketplace were flagged as vulnerable (The Hacker News).

What We Don’t Know

• Whether any package was actually hijacked. The Hacker News describes the flaw and the number of vulnerable packages but does not report a confirmed malicious publication through a reclaimed slug.
• How the 1,500 figure was derived. The count and the download total are Bloom Security’s, as relayed by The Hacker News, which does not detail the methodology. GitHub’s changelog entry, as summarized above, does not mention the research or the count.
• How many configurations expired. The changelog entry describes the rule but not how many existing configurations it affected.