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 | 3 | |
| Total downloads, more than | 10,000,000 downloads | 4 | |
| Average monthly downloads per exposed package, about | 670 a month | Average across the exposed packages | 17 |
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
- Who has to decide 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.
- What it limits 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.
- Who's exposed 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.
Next story · Security · 4d ago
GitLab patches a maximum-severity code execution flaw in its CI/CD regex compilerConfirmed7 publishers
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 [13]. 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 [14].
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 [4]. That averages about 670 a month per package [17]. But a malicious version can carry a postinstall script, and npm runs it automatically on every machine that installs the update [23].
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 [22]. A GitHub spokesperson then told Help Net Security: "Unvalidated Trusted Publishing configurations now expire 48 hours after creation and can no longer authorize publishing." [8]
GitHub's statement does not say whether configurations that published before the change were bound retroactively [18]. We think the 1,500 figure cannot be read as closed until that is answered [18].
Myers said it is unknown whether anyone exploited the flaw in the wild [19]. In our view the fault is in how the binding was designed: Bloom says npm's GitLab trusted publishing integration has the same weakness [25].
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
- Not scored
- Hype gap+20
- Incentives55
- Confidence64
Perspective Coverage
3 publishers- Builder
- Builder 45%
- Operator
- Operator 38%
- Investor
- Investor 17%
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]
Bloom counted more than 1,500 npm packages exposed this way.
- [4]
The exposed packages have more than 10 million downloads in total and more than a million a month.
- [5]
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.
- [6]
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.
- [7]
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.
- [8]
"Unvalidated Trusted Publishing configurations now expire 48 hours after creation and can no longer authorize publishing."
- [9]
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."
- [10]
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.
- [11]
Users can verify that a package's provenance attestation names the repository the project is supposed to come from.
- [12]
GitHub, which owns npm, says it has shipped fixes.
- [13]
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.
- [14]
"We took this into account. Everything we considered vulnerable was pertaining to claimable slugs,"
- [15]
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.
- [16]
A release published this way also carries a valid provenance attestation, a signed build record, naming the attacker's repository.
- [17]
Across the exposed packages, downloads average about 670 a month per package.
- [18]
GitHub's statement does not say whether configurations that published before the change were bound retroactively.
- [19]
Myers said it is unknown whether anyone exploited the flaw in the wild.
- [20]
Bloom is not publishing the affected package names, so users of npm packages cannot check against a list.
- [21]
Bloom reported the issue through GitHub's bug bounty program on HackerOne on June 6, and GitHub validated it on June 9.
- [22]
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.
- [23]
A malicious version can carry a postinstall script, code that npm runs automatically on every machine that installs the update.
- [24]
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.
- [25]
Bloom says npm's GitLab trusted publishing integration has the same weakness.
Sources
3 independent publishers whose own reporting we read for this story.
- dev.toNew stricter rules from GitHub for code packages after security investigation
1 article · October 13, 2026
- helpnetsecurity.comnpm Trusted Publishing flaw exposed 1,500+ npm packages to takeover
1 article · October 13, 2026
- thehackernews.comGitHub Tightens npm Publishing After Flaw Left 1,500+ Packages Vulnerable to Hijacking
1 article · October 13, 2026
Topics and entities
Topics
- Software Supply Chain Security
- Package Registry Security
- AI Coding Agents
Entities
- HackerOne
- npm Trusted Publishing
- npm registry
- GitLab
- GitHub