GitHub Fixes npm Trusted Publishing Flaw Exposing 1,500 Packages to Takeover
Researchers found that npm’s Trusted Publishing feature allowed attackers to publish malicious updates without stealing credentials by claiming abandoned repository names.
Key points
- Bloom Security identified more than 1,500 npm packages vulnerable to takeover via the Trusted Publishing feature.
- Attackers could push new versions by registering GitHub repository slugs that maintainers had previously abandoned or deleted.
- GitHub has shipped fixes for the flaw after validating the report through its bug bounty program.
GitHub has released fixes for a security flaw in npm’s Trusted Publishing feature that allowed attackers to publish new versions of packages they did not own. Bloom Security researchers discovered that the vulnerability exposed more than 1,500 packages to potential takeover without the need to steal maintainer credentials.
The flaw permitted attackers to push malicious updates by simply registering a GitHub repository name that a package maintainer had left behind. According to Help Net Security, this issue affected packages with more than 10 million total downloads and over a million monthly downloads. A single compromised package could distribute harmful code to thousands of users.
How the Vulnerability Worked
Trusted Publishing, which became generally available in July 2025, was designed to replace long-lived publishing tokens with temporary, workflow-based credentials. The feature allows maintainers to specify which GitHub repository and workflow file are authorized to publish a specific npm package. When an authorized workflow runs, GitHub issues a signed identity token.
npm exchanged this token for a publish credential that expired within minutes. However, npm recorded the authorized repository only by its name, known as a slug. GitHub assigns both a permanent numeric ID and a name to every repository and owner, and includes both in the token. npm failed to verify the numeric IDs during the exchange process.
This oversight meant that if a maintainer renamed, transferred, or deleted their bound repository, or if the owner account was renamed or deleted, the old slug became available for registration. Any user could then create a new repository with that name, add a workflow file with the matching filename, and receive a valid publish credential for the package.
Bloom Security researchers demonstrated the attack end-to-end on a package and repositories they controlled. They published a release from a second organization’s repository that had claimed the freed slug. The malicious release carried a valid provenance attestation, a signed build record that named the attacker’s repository as the source, potentially misleading security tools.
Impact and Disclosure Timeline
The exposed packages averaged several hundred monthly downloads each, but the risk remained significant because a single hijacked package could carry a postinstall script. This code runs automatically on every machine that installs the update, allowing attackers to execute arbitrary commands on victim systems.
GitHub mitigates some risks by retiring the names of repositories with more than 100 clones in the week before an owner account is renamed or deleted. Golan Myers, a security researcher at Bloom Security, stated that their analysis focused specifically on claimable slugs, noting that the company took this retirement policy into account.
Bloom Security reported the issue through GitHub’s bug bounty program on HackerOne on June 6. GitHub validated the finding on June 9. According to Help Net Security, Bloom received its last reply on July 8. The research firm sent six follow-up messages after that date, including a mediation request to HackerOne, which went unanswered.
What should you do?
Organizations should review their npm dependencies for any packages that may have been affected by this vulnerability. While GitHub has shipped fixes, users should ensure their environments are updated to the latest versions of npm and related tooling to benefit from the patch.
Monitor installation logs for unexpected postinstall scripts or changes in package provenance attestations. Verify that the repositories publishing your dependencies match the expected owners and have not been recently renamed or transferred.
What to do and how to stay safe: npm
- Audit your npm packages to identify any that were among the 1,500+ exposed packages identified by Bloom Security.
- Ensure your npm client and related tools are updated to the latest version once the vendor provides an update.
- Monitor package provenance attestations and installation logs for unexpected changes or scripts from untrusted repositories.
- Verify that the GitHub repositories associated with your dependencies have not been recently renamed, transferred, or deleted.
Step-by-step guide: Risk Based Vulnerability Management: Prioritize Fixes by Actual Threat
General security guidance from the Threat Times newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What is npm Trusted Publishing?
Trusted Publishing is a feature that replaces long-lived tokens with temporary credentials issued by GitHub workflows, allowing maintainers to specify which repositories can publish their packages.
How did attackers exploit this flaw?
Attackers exploited the flaw by registering GitHub repository slugs that maintainers had abandoned, allowing them to receive valid publish credentials for packages they did not own.
Has this issue been fixed?
Yes, GitHub says it has shipped fixes for the vulnerability after validating the report from Bloom Security researchers.
