SecurityNot yet confirmed elsewhere1 publisher2 min readPublished
npm Trusted Publishing accepted a freed GitHub repo name as proof of who may publish
Bloom Security counted more than 1,500 npm packages exposed because Trusted Publishing bound publish rights to a GitHub repository name. GitHub says it has shipped fixes, and Bloom's Golan Myers said it is unknown whether anyone exploited the flaw.
The Watch · Security desk
Key figures: Bloom Security counted more than 1,500 npm packages exposed. Those packages have more than 10 million downloads in total, averaging about 670 downloads a month per package.
| Figure | Value | Note | Claim |
|---|---|---|---|
| npm packages Bloom counted as exposed, more than | 1,500 packages | 19 | |
| Total downloads, more than | 10,000,000 downloads | 20 | |
| Average monthly downloads per exposed package, about | 670 a month | Average across the exposed packages | 16 |
What happened
- npm stored the bound repository as an owner/repo string and did not check the permanent numeric IDs that GitHub puts in every identity token.
- After a rename, transfer or deletion freed the old name, anyone could create a repository there, add a matching workflow file and receive a publish credential.
- Bloom's researchers carried out the full attack against a package and repositories under their own control, with the publish coming from a repository belonging to a second organization.
- Bloom filed its report on June 6 through GitHub's HackerOne bug bounty program. GitHub's validation followed on June 9.
- GitHub's change was announced on October 2. According to npm's documentation, the first successful publish under a configuration ties that configuration to the repository's immutable identity.
Why it matters
- decision Maintainers have a short audit: run npm trust list, confirm each repository is still one they control, re-create bindings to renamed or transferred repositories, and remove a binding before deleting its repository.
- constraint A release published through the flaw carries a valid provenance attestation, so validity alone does not show the intended source; users must read the repository it names, and Bloom is withholding package names.
- exposure Bloom estimates AI agents install about 70 packages a month on a typical endpoint and close to 350 on developer machines, usually without reviewing the package or its maintainer.
GitHub's name retirement narrows the set. When an owner account is renamed or deleted, GitHub retires the name of any repository that drew more than 100 clones in the preceding week [8]. That protects some packages. "We took this into account. Everything we considered vulnerable was pertaining to claimable slugs," said Golan Myers, security researcher at Bloom Security [9].
The reach of any one package is small. Together, the exposed packages account for over 10 million downloads in total and over a million every month [20]. That averages about 670 a month per package [16]. But a malicious version can carry a postinstall script, and npm runs it automatically on every machine that installs the update [24].
The disclosure went quiet before the fix. Bloom says GitHub's last reply came on July 8 and that six follow-ups after it, including a mediation request to HackerOne, went unanswered [18]. A GitHub spokesperson then told Help Net Security: "Unvalidated Trusted Publishing configurations now expire 48 hours after creation and can no longer authorize publishing." [10]
GitHub's statement does not say whether configurations that published before the change were bound retroactively [21]. We think the 1,500 figure cannot be read as closed until that is answered [21].
Myers said it is unknown whether anyone exploited the flaw in the wild [22]. In our view the fault is in how the binding was designed: Bloom says npm's GitLab trusted publishing integration has the same weakness [23].
What to watch
- Whether GitHub or npm confirms that bindings which published before October 2 are now tied to immutable IDs.
- Any report of a package published through a freed slug outside Bloom's controlled test.
- Whether npm applies the same identity check to its GitLab trusted publishing integration, which Bloom says has the same weakness.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence62
- Adoption
- Insufficient
- Hype gap+10
- Incentives
- Insufficient
- Confidence58
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
Bloom Security researchers found that npm's Trusted Publishing feature let an attacker push new versions of someone else's package without stealing a credential.
- [2]
The attacker only needed to register a GitHub repository name the maintainer had left behind.
- [3]
Trusted Publishing, generally available since July 2025, replaces long-lived publishing tokens; GitHub issues the workflow a signed identity token and npm exchanges it for a publish credential that expires within minutes.
- [4]
npm recorded the bound repository by its owner/repo slug; GitHub also assigns permanent numeric IDs to every repository and owner that survive renames and transfers and puts both IDs in the token, and npm did not check them.
- [5]
Once a maintainer renamed, transferred or deleted the bound repository, or the owner account was renamed or deleted, the old slug was free; anyone could create a repository at that name, add a workflow file with the matching filename, and receive a publish credential for a package they did not own.
- [6]
Bloom ran the attack end to end on a package and repositories its researchers controlled, publishing from a second organization's repository that had claimed the freed slug.
- [7]
A release published this way also carries a valid provenance attestation, a signed build record, naming the attacker's repository.
- [8]
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.
- [9]
"We took this into account. Everything we considered vulnerable was pertaining to claimable slugs,"
- [10]
"Unvalidated Trusted Publishing configurations now expire 48 hours after creation and can no longer authorize publishing."
- [11]
GitHub announced the change on October 2, and npm's documentation says a configuration's first successful publish binds it to the repository's "immutable identity."
- [12]
Bloom is not publishing the affected package names, so users of npm packages cannot check against a list.
- [13]
Maintainers with Trusted Publishing should run npm trust list and confirm each listed repository still resolves to one they control, delete and re-create any binding that points at a renamed or transferred repository, and remove the binding before deleting a repository.
- [14]
Users can verify that a package's provenance attestation names the repository the project is supposed to come from.
- [16]
Across the exposed packages, downloads average about 670 a month per package.
- [17]
Bloom reported the issue through GitHub's bug bounty program on HackerOne on June 6, and GitHub validated it on June 9.
- [18]
Bloom says the last reply it got from GitHub was on July 8, and that six follow-ups after that, including a mediation request to HackerOne, went unanswered.
- [19]
Bloom counted more than 1,500 npm packages exposed this way.
- [20]
The exposed packages have more than 10 million downloads in total and more than a million a month.
- [21]
GitHub's statement does not say whether configurations that published before the change were bound retroactively.
- [22]
Myers said it is unknown whether anyone exploited the flaw in the wild.
- [23]
Bloom says npm's GitLab trusted publishing integration has the same weakness.
- [24]
A malicious version can carry a postinstall script, code that npm runs automatically on every machine that installs the update.
- [25]
Based on telemetry from dozens of organizations, Bloom estimates that AI agents on a typical endpoint install about 70 packages a month, and close to 350 on developer machines, not counting dependencies; those installs usually happen without a review of the package or its maintainer.
Sources
1 independent publisher whose own reporting we read for this story.
- helpnetsecurity.comnpm Trusted Publishing flaw exposed 1,500+ npm packages to takeover
1 article · October 13, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.