Update npm Trusted Publishing Configuration to Prevent Package Hijacking
GitHub has fixed a flaw in npm Trusted Publishing that allowed attackers to publish malicious code to over 1,500 packages by claiming old repository names.
Key points
- Bloom Security identified a flaw allowing package takeover without credential theft.
- More than 1,500 npm packages were exposed to potential hijacking.
- GitHub has shipped fixes for the Trusted Publishing feature.
System administrators must verify that their organization uses updated versions of npm and GitHub workflows. A security flaw in the Trusted Publishing feature allowed attackers to publish new versions of packages they did not own. This occurred without stealing any login credentials or tokens from the original maintainers. The issue stemmed from how repository names were tracked during the publishing process.
In plain English
The Trusted Publishing feature is designed to replace long-lived tokens with temporary, secure credentials. It links a specific GitHub repository to an npm package. When a workflow runs, GitHub issues a signed token that npm exchanges for a short-lived publishing credential. This method was intended to improve security by eliminating the risk of stolen permanent tokens.
However, npm recorded the repository connection using only its human-readable name, known as a slug. It did not verify the permanent numeric ID assigned by GitHub to that repository. This numeric ID remains constant even if the repository is renamed, transferred, or deleted. Because npm ignored this permanent identifier, the link between the package and the repository became fragile.
If a maintainer renamed, transferred, or deleted their GitHub repository, the old name became available for anyone to register. An attacker could create a new repository with that exact name. By adding a workflow file with the matching filename, the attacker could trick the system into issuing a valid publishing credential. This allowed them to push malicious updates to the original package.
The background
Bloom Security researchers discovered this vulnerability and reported it through GitHub’s bug bounty program on HackerOne. They counted more than 1,500 npm packages that were exposed to this type of takeover. The exposed packages have collectively received more than 10 million downloads, with over a million downloads occurring each month.
The researchers demonstrated the attack end-to-end on packages they controlled. They published a version from a second organization’s repository that had claimed the freed slug. The malicious release carried a valid provenance attestation, which is a signed build record. This attestation incorrectly named the attacker’s repository as the legitimate source, making the malicious version appear trustworthy to automated systems.
GitHub validated the issue on June 9, according to Help Net Security. Bloom Security states that the last reply from GitHub was on July 8. The researchers reported that six follow-up messages, including a mediation request to HackerOne, went unanswered after that date. GitHub has since confirmed that it has shipped fixes for the flaw.
What changes now
GitHub retires the names of repositories with more than 100 clones in the week before an owner account is renamed or deleted, which protects some packages. Golan Myers, a security researcher at Bloom Security, noted that their analysis focused only on claimable slugs. This means the 1,500+ packages identified were those where the old repository name was still available for registration. GitHub says it has shipped fixes for the Trusted Publishing feature.
What to do and how to stay safe: npm
- Audit your GitHub repositories to ensure no old or deleted names are being reused for new projects.
- Review your npm package dependencies to confirm you are using versions published after the fix was shipped.
- Monitor your build logs for any unexpected provenance attestation changes or new publishers for critical packages.
- Once the vendor provides an update, ensure your CI/CD pipelines are configured to use the latest npm client.
Step-by-step guide: Risk-Based Vulnerability Management: Benefits, Limits, and Reality
General security guidance from the Vector Update newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Did attackers actually steal credentials to publish these malicious packages?
No, the flaw allowed attackers to publish new versions without stealing any credentials or tokens from the original maintainers.
How many packages were exposed to this vulnerability?
Bloom Security counted more than 1,500 npm packages that were exposed to potential takeover via this method.
When did GitHub confirm the issue was fixed?
GitHub says it has shipped fixes, though the source material does not provide a specific release date for the update.
