npm Trusted Publishing flaw exposed over 1,500 packages to takeover

Researchers at Boom Security identified the vulnerability, though other reports refer to the firm as Bloom Security. Their analysis uncovered more than 1,500 potentially vulnerable npm packages linked to the flaw. These exposed packages account for over 10 million downloads in total and more than one million per month.

The issue stems from how npm verifies trusted publishers through human-readable repository names rather than permanent identifiers. Researchers named the vulnerability SlugFest due to this reliance on shared repository naming conventions. An attacker could inherit a package’s publishing trust by claiming a GitHub repository name that its original owner had abandoned.

The researchers successfully demonstrated the attack by publishing a new version of an existing package under their own controlled testing conditions. This method did not require compromising the legitimate maintainer’s GitHub or npm account credentials.

GitHub shipped a fix on October 2 to address the exposure associated with unvalidated configurations. The update introduces a 48-hour expiry for Trusted Publishing configurations that lack validation before publishing. Additionally, npm tightened safeguards by rejecting trusted-publishing tokens issued through specific GitHub Actions events.

AI coding agents amplify the supply-chain risk by selecting and installing software packages with limited human intervention. Telemetry suggests agents on typical endpoints install about 70 packages a month, rising to around 350 on developer machines. This automation means a malicious release could execute code without a developer explicitly selecting it.

Maintainers are advised to review their existing trust relationships and verify that each repository name still resolves to a controlled asset. The company recommended removing and recreating bindings where necessary to ensure security integrity. Users can check package provenance attestations to confirm the software originates from the expected repository.

Bloom Security reported the issue through GitHub’s bug bounty program on HackerOne on June 6 and received validation on June 9. The firm noted that six follow-ups after July 8 went unanswered during the disclosure process. A spokesperson confirmed they worked to validate the report and ship fixes to remediate the issue.