Organisations urged to audit npm trust configs after GitHub patches flaw risking 10M downloads

Organisations relying on npm dependencies faced a significant supply-chain risk when a validation flaw in Trusted Publishing was exposed. Researchers at Bloom Security identified more than 1,500 packages that could be hijacked by attackers reclaiming abandoned GitHub repository names. This vulnerability, dubbed SlugFest, threatened the integrity of widely used software components without requiring credential theft.

How did the vulnerability allow package takeover?

The flaw stemmed from how npm verified trusted publishers. Instead of using permanent numeric identifiers, the system relied on human-readable repository names, known as slugs. When a maintainer deleted or renamed a repository, the slug became available for others to claim. An attacker could then create a new repository with that name and configure a matching workflow file.

npm would issue a valid publishing credential to this new repository because it did not check the underlying repository ID. This meant an attacker could push malicious versions of a package they did not own. The researchers demonstrated this end-to-end, publishing a new version from a controlled repository belonging to a different organisation.

What is the scope of the exposure?

Bloom Security counted more than 1,500 exposed packages, which collectively account for over 10 million total downloads and more than one million monthly downloads. The affected software includes security scanners, authentication tools, and cryptographic packages. While the average monthly downloads per package are several hundred, even a single compromised package can carry a malicious postinstall script.

This script runs automatically on every machine that installs the update, posing a severe risk to CI/CD systems and developer environments. The researchers noted that a successful takeover could deliver harmful code under a legitimate package name. They compared this risk to the recent ChainDrop npm worm, which showed how compromised releases can spread through automated build environments.

When was the issue reported and fixed?

Bloom Security reported the vulnerability through GitHub’s bug bounty program on HackerOne on 6 June. GitHub validated the issue on 9 June, but Bloom stated that subsequent follow-ups, including a mediation request, went unanswered after 8 July. The npm team confirmed that a fix was shipped on 2 October.

The update introduces a 48-hour expiry for unvalidated Trusted Publishing configurations. This change addresses the exposure associated with unvalidated trust relationships. However, maintainers still need to review their existing configurations to ensure they are secure. The researchers confirmed that the fix resolves the specific slug reuse issue that enabled the takeover.

What does this mean for organisations?

The incident highlights the risks of relying on mutable identifiers for security-critical operations. Although no active exploitation was observed in the wild, the flaw was successfully demonstrated in controlled testing. Organisations must verify that their npm dependencies are not affected by this configuration gap.

Maintainers should ensure their Trusted Publishing setups use validated configurations that include permanent repository IDs. The 48-hour expiry window for unvalidated setups provides a buffer, but proactive review is essential. This event underscores the importance of robust identity verification in software supply chains.

What to do and how to stay safe: npm

• Audit npm package configurations to ensure Trusted Publishing uses validated settings with permanent repository IDs.
• Monitor dependency updates for unexpected changes, especially in security-critical packages like authentication tools.
• Implement strict code review processes for any new versions of packages, checking for malicious postinstall scripts.
• Stay informed about vendor updates and apply fixes promptly once the vendor provides an update.

General security guidance from the Phish Herald newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Was this vulnerability actively exploited in the wild?

No, Bloom Security stated they have not observed active exploitation, though they successfully demonstrated the attack in controlled conditions.

How many packages were affected by the SlugFest vulnerability?

More than 1,500 npm packages were identified as potentially vulnerable, with over 10 million total downloads.

What fix did GitHub implement to address the issue?

GitHub shipped a fix on 2 October that introduces a 48-hour expiry for unvalidated Trusted Publishing configurations.