npm Trusted Publishing Flaw Exposes 1,500+ Packages to Takeover

npm Trusted Publishing flaw compromised over 1,500 packages through repository name manipulation

Discovery of the Vulnerability

Bloom Security researchers uncovered a critical vulnerability in npm’s Trusted Publishing system that allowed unauthorized individuals to gain control of software packages without compromising credentials.

How the Flaw Worked

Vulnerability Mechanism

The flaw leveraged a gap in how npm validated repository identifiers, enabling attackers to exploit renamed or deleted GitHub repositories to generate valid publishing credentials for third-party packages.

Trusted Publishing Feature

The Trusted Publishing feature, introduced in July 2025, replaced long-term publishing tokens with a workflow-based authentication model. Maintainers link their packages to specific GitHub repositories and workflow files.

Repository Slug Vulnerability

npm only stored the repository’s human-readable slug (e.g., owner/repo) rather than its unique numeric identifier. This oversight allowed attackers to seize control of packages by registering repositories with freed slugs.

Exploit Details

Attack Process

Once a repository’s slug became available—due to renaming, deletion, or account changes—any attacker could create a matching repository, configure a workflow, and obtain a valid publishing credential.

Forged Provenance Attestation

The resulting package updates carried a forged provenance attestation, falsely attributing the build to the attacker’s repository.

Demonstration of the Exploit

Bloom Security demonstrated the exploit by publishing updates to a controlled package using a repository that had claimed a freed slug.

GitHub’s Response

Partial Protection Mechanism

GitHub’s existing mechanism to retire repository names after 100 clones in the week before an account deletion provided partial protection, but Bloom confirmed the flaw remained exploitable for packages tied to claimable slugs.

Report and Follow-Up

A researcher from Bloom noted that the issue was reported via GitHub’s bug bounty program on June 6, with initial validation on June 9. Subsequent follow-ups, including mediation requests, went unanswered, according to the team.

Fix and Ongoing Concerns

GitHub’s Fix

GitHub addressed the vulnerability by updating its systems on October 2, requiring Trusted Publishing configurations to bind to a repository’s immutable numeric ID rather than its slug.

Retroactive Updates

However, the company has not clarified whether existing configurations were retroactively updated.

Implications and Risks

Real-World Exploitation

The extent of real-world exploitation remains unknown.

AI-Driven Development Risks

The flaw’s implications are amplified by the growing reliance on AI-driven development tools. Bloom estimates that AI coding agents install an average of 70 packages monthly on endpoints and up to 350 on developer machines, often without manual review.

Recommendations for Maintainers

Audit Configurations

Maintainers are advised to audit their Trusted Publishing configurations using the npm trust list command and verify that all linked repositories remain under their control.

Reconfigure Bindings

Any bindings to renamed, transferred, or deleted repositories should be removed and reconfigured.

User Actions

Validate Provenance

Users cannot directly check affected packages, as Bloom has not disclosed specific names. Instead, they should validate a package’s provenance attestation to ensure it originates from the expected repository.

Broader Supply Chain Risks

GitLab Integration Vulnerabilities

Bloom also identified similar vulnerabilities in npm’s GitLab integration, highlighting broader risks in supply chain authentication mechanisms.

Conclusion

The incident underscores the need for robust verification processes in software distribution systems, particularly as automation and AI tools expand their role in development workflows.

About Author