A Leftover GitHub Repo Name Was Enough to Hijack npm Packages: The Trusted Publishing Flaw at a Glance

Trusted Publishing was supposed to make the JavaScript package registry npm safer by getting rid of long-lived publishing tokens. Researchers have now shown that, until recently, it trusted the wrong thing: a repository’s name rather than its permanent identity. The essentials are below, followed by what to check.

The details come from Mirko Zorz’s report at Help Net Security, which covers Bloom Security’s research and GitHub’s response.

The flaw on one page

• Feature: npm Trusted Publishing, generally available since July 2025. A maintainer names the GitHub repository and workflow file allowed to publish a package. When that workflow runs, GitHub issues a signed identity token, and npm swaps it for a publishing credential that expires within minutes.
• The weak point: npm recorded the repository by its owner/repo name, which GitHub calls a slug. GitHub’s token also carries permanent numeric IDs for the repository and owner that survive renames and transfers, but npm didn’t check them.
• How it opens up: if the bound repository is renamed, transferred or deleted, or the owner account is renamed or deleted, the old name becomes free. Anyone can then create a repository with that name, add a workflow file with the matching filename and receive a publishing credential for a package they don’t own. No stolen password or token is needed.
• Scale: more than 1,500 exposed packages, with more than 10 million downloads in total and over a million a month.
• Why it is dangerous: a hijacked release can include a postinstall script, code npm runs automatically on every machine that installs the update. It would also carry a valid provenance attestation, a signed build record, naming the attacker’s repository.
• Partial safety net: 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. Bloom says its count only includes names that could actually be claimed.
• Proof: Bloom ran the full attack against a package and repositories its own researchers controlled.
• Disclosure: reported through GitHub’s HackerOne bug bounty on June 6 and validated on June 9. Bloom says its last reply came July 8 and six later follow-ups went unanswered.
• Fix: GitHub announced a change on October 2. Trusted Publishing configurations that haven’t been validated now expire 48 hours after creation and can no longer authorize publishing, and npm’s documentation says a configuration’s first successful publish ties it to the repository’s permanent identity.
• Open questions: GitHub hasn’t said whether configurations that published before the change were bound retroactively, and it is unknown whether anyone exploited the flaw. Bloom also says npm’s GitLab trusted publishing integration has the same weakness.
• The AI angle: based on telemetry from dozens of organizations, Bloom estimates AI coding agents on a typical endpoint install about 70 packages a month, and close to 350 on developer machines, not counting dependencies, usually with no review.

Checklist

If you publish npm packages

• Run the command “npm trust list” and confirm every listed repository still points to one you control.
• Delete and re-create any binding that refers to a renamed or transferred repository.
• Remove the Trusted Publishing binding before you delete a repository, not after.

If you only install npm packages

• Bloom isn’t publishing the list of affected packages, so there’s nothing to compare against. Instead, check that a package’s provenance attestation names the repository the project is supposed to come from.

What this means for your company

Even if nobody at your company writes code, your website, online store or customer portal almost certainly depends on open-source packages chosen by a developer or agency, and increasingly by AI tools working on their behalf. A few questions to put to whoever builds your software:

• Do you lock dependency versions, so updates arrive only when someone decides to take them?
• Who reviews new packages before they go into our projects, including ones an AI assistant adds?
• If we publish any packages or libraries, have the Trusted Publishing bindings been checked since this research came out?
• Do build machines and developer laptops run endpoint protection that would notice an install script doing something unusual?

Need help putting guardrails around the open-source code your developers and AI tools bring in? Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.

About The Author

L7 News

See author's posts