npm Trusted Publishing: SlugFest flaw exposed 1,500 packages

Researchers at Bloom Security found that Trusted Publishing, the npm mechanism that replaces long-lived publishing tokens, made it possible to publish new versions of someone else’s package without stealing any credential: all it took was registering on GitHub a repository name the maintainer had left free. According to Bloom, more than 1,500 packages were exposed. The vulnerability, dubbed SlugFest, has been fixed by GitHub, which owns npm, with a change announced on 2 October 2026. Help Net Security, CSO Online and The Hacker News reported on it on 13 October.

What happened

Trusted Publishing, generally available since July 2025, is based on OpenID Connect: the maintainer tells npm which GitHub repository and which workflow file may publish the package. When the workflow runs, GitHub issues it a signed identity token, which npm exchanges for a publishing credential valid for a few minutes.

The problem, according to Bloom, lay in how npm verified the repository: only by its human-readable owner/repo name (the slug) and the workflow file name. GitHub also assigns every repository and every owner a permanent numeric ID, which does not change with renames and transfers and is already included in the token, but npm did not check it.

Bloom demonstrated the attack end to end on a package and repositories under its own control, publishing a new version from the repository of another organisation that had claimed the freed name. According to CSO Online, the researchers say they have not observed exploitation in the wild; they told Help Net Security it is unknown whether anyone has used the flaw.

Technical details

The chain described by the sources is as follows:

1. the maintainer renames, transfers or deletes the repository linked to the package, or renames or deletes the owner account, without removing the Trusted Publishing configuration;
2. the old slug becomes available again;
3. the attacker creates a repository with that name and adds a GitHub Actions workflow with the same file name expected by the configuration;
4. npm accepts the token and issues the publishing credential: the attacker publishes a new version of the package.

Neither the compromise of the maintainer’s GitHub or npm account nor credential theft is required. A version published this way also carries a valid, signed provenance attestation, which however names the attacker’s repository. A malicious version can contain a postinstall script, which npm runs automatically on every machine that installs the update, CI pipelines included.

According to Help Net Security, GitHub already retires the names of repositories with more than 100 clones in the week before the owner account is renamed or deleted: this protected part of the packages, and Bloom says it took this into account by counting only slugs that could actually be claimed.

Bloom’s figures: over 1,500 packages, more than 10 million total downloads and more than one million a month. According to CSO Online a single package exceeded 200,000 monthly downloads, and the exposed packages include security scanners, authentication tools and cryptographic libraries. Bloom is not publishing the package names. Also according to Bloom, as reported only by Help Net Security, npm’s Trusted Publishing integration with GitLab has the same weakness.

In our reading, the relevant MITRE ATT&CK technique is T1195.001 (Compromise Software Dependencies and Development Tools).

The fix and the timeline

According to what Bloom told Help Net Security, the report was submitted through GitHub’s bug bounty programme on HackerOne on 6 June and validated on 9 June; the last reply it received dates back to 8 July, and six later follow-ups, including a mediation request to HackerOne, went unanswered.

The changes, according to GitHub and the npm documentation cited by the sources:

• unvalidated Trusted Publishing configurations expire 48 hours after creation and can no longer authorise publishing;
• the first successful publish binds the configuration to the repository’s immutable identity;
• according to CSO Online, npm now also rejects tokens issued by workflows triggered by the issue_comment event, in addition to the existing restriction on pull_request_target.

Help Net Security notes that GitHub’s statement does not clarify whether configurations that had already published before the change were bound to the identity retroactively. This is why Bloom asks maintainers to review their existing configurations anyway.

Impact for European and Italian companies

npm is the reference registry for JavaScript and TypeScript: it is used by web applications, development tools and build pipelines in almost every company that develops software. A hijacked package runs code on developer workstations and CI runners, where tokens, keys and access to production systems are found.

Bloom highlights the role of AI coding agents: from data collected across a few dozen organisations, it estimates about 70 packages installed by agents each month per endpoint, and about 350 on developer machines, not counting dependencies, usually without any review of the package or its maintainer.

For NIS2 entities, supply chain and development security is one of the required measures: a case like this should be considered both for the software the company publishes on npm and for the software it uses.

What to do now

1. If you publish packages with Trusted Publishing: run npm trust list and check that every listed repository still exists and is under your control. Delete and re-create configurations pointing to renamed or transferred repositories, and remove the configuration before deleting a repository or renaming an account.
2. Check the version history of your packages: versions you do not recognise, or with a provenance attestation naming a repository other than yours, should be withdrawn and reported.
3. If you use npm packages: since there is no list to check against, verify that the provenance attestation of new versions names the repository the project is supposed to come from.
4. Reduce the impact of install scripts: pin versions with the lock file and, where possible, disable install scripts in pipelines (--ignore-scripts).
5. Govern installations by AI agents, as Bloom recommends: decide what developers and agents are allowed to install and keep an inventory of the dependencies and tools in use.

How ARXDOME helps

ARX Sentry collects the software and process inventory of computers and servers: it helps you know where development tools and runners that need checking are running. If a machine has installed a suspicious version, ARX Shield lets you isolate it from the network while checks and secret rotation are carried out.

Last updated: 13 October 2026