npm Trusted Publishing checked a name, not an ID, until first publish: Bloom counts 1,500+ packages exposed

The missing check was a number GitHub had already sent

Bloom Security's own write-up says that when a build job asked npm for permission to publish, npm's Trusted Publishing compared two things with what the maintainer had registered: the repository's owner and name, and the workflow file's name. GitHub's signed identity token also carries two permanent numeric IDs, one for the repository and one for its owner. Bloom says npm stored those IDs only after a configuration's first successful publish. Until then, the one thing a re-registered name cannot copy was not checked. npm's own documentation describes the same moment: the first successful publish "validates the configuration and binds it to the repository's immutable identity".

That makes the flaw narrower than Help Net Security's summary reads, which leaves the condition out; Bloom's page and some other coverage state it. Bloom states the precondition itself: the binding had to point at an owner and name that an outsider could register, and it had to be a binding that had never been used to publish. Bloom says it ran the attack end to end against an npm scope and GitHub repositories it controls, that a release published this way carries a valid provenance attestation naming the other repository, and that it counted more than 1,500 npm packages exposed, with over 10 million downloads in total and over a million a month.

What the record does not establish is most of what a reader needs. No source read reports a real package taken over this way: a Bloom researcher told Help Net Security that it is unknown whether anyone exploited the flaw. Bloom has not published the list of packages, the date of its scan, or whether and how it limited the count to bindings that had never published. GitHub's statement gives the fix but no dates, no count, and no word on whether older, never-used bindings were expired. The sections below set out each gap.

Three words in this story sound like controls and are not one unless the binding is to an immutable identifier: trusted, provenance and verified. Bloom's own summary of the lesson is short: "A name is not an identity." This briefing read Bloom's write-up, GitHub's changelog post and npm's documentation directly, from 11:17 BST on 13 October 2026. Help Net Security's report of the same day was used as the pointer and for GitHub's statement, which Bloom's page does not carry.

Five steps from a freed name to a signed release

The sequence is drawn from Bloom's write-up and npm's documentation, at the level of the class of flaw. It is not a procedure: no package, repository or workflow is named, and the diagram carries no file contents or requests. The red box is where the check was missing. The two cards under the five boxes are the missing check and what GitHub changed on 2 October.

Two details matter for what follows. First, step 2 needs the name to be free. GitHub's pages, read for this briefing, say it permanently retires an owner and repository name combination when an account is renamed or a repository is transferred, if the repository held a Marketplace action or had more than 100 clones or more than 100 Actions uses in the week before. Help Net Security puts the rule as clones only, and as applying to renamed or deleted owners. The GitHub pages read on renaming a repository, deleting a repository and deleting an account do not mention retirement, so for those cases the protection is not stated.

Second, step 4 is the whole flaw. A repository registered at a freed name gets new numeric IDs from GitHub, and both are in the token npm was already receiving. Bloom's proposed fix is one comparison: store the IDs when the binding is made and reject a token whose IDs differ. Bloom says PyPI already works this way. PyPI's own page, read for this briefing, describes the owner ID version of it, and the table of other registries below sets it out.

Stated and not stated: the record, line by line

The table separates what the sources state from what none of them states. "Not stated" means not found in Bloom's write-up, GitHub's changelog, GitHub's statement as reported by Help Net Security, or npm's documentation. It does not mean the information does not exist.

What the sources state and do not state, read on 13 October 2026. Bloom's own account is marked as such: GitHub has given no dates.

The question	Stated	Not stated
Was any package hijacked?	Bloom ran the attack end to end on an npm scope and GitHub repositories it controls. A Bloom researcher told Help Net Security it is unknown whether anyone exploited it. Cyberpress says the research describes potential exploitation and a controlled demonstration, not confirmed takeovers across the identified packages.	Any real hijacked release, or any check of past publishes. Bloom says it blocked a customer's agent trying to install one counted package. That is an install attempt, and the package is not said to be malicious.
How many packages?	More than 1,500 with a trusted publisher and a claimable name, over 10 million downloads in total, over a million a month (Bloom). A researcher said retired names were excluded.	The scan date, the rule for claimable, whether and how Bloom limited the count to bindings that had never published, the period behind total downloads, any list. Bloom's reason for withholding the list is that the issue is "still prevalent", on a page that also says a fix is in place.
What did GitHub change?	From 2 October 2026 a configuration with no successful publish expires 48 hours after creation and cannot authorise publishing. A first publish validates it. GitHub told Help Net Security the change "limits the risk" of trusting a name that changes ownership.	Any lookup of the numeric IDs when a binding is created. Whether never-published bindings made before 2 October were expired, when, or how many.
Who knew what, and when?	Bloom: reported 6 June, validated 9 June, last reply 8 July, six follow-ups unanswered, including a mediation request, then a reply that apologised and confirmed the fix. GitHub: it learned of the issue through its bug bounty and "worked to validate the report".	GitHub's own dates and reasons, any bounty or credit, and the date of the apology. The changelog does not mention a report or a researcher. The HackerOne report was not found public.
Does it reach other providers?	GitHub's post says repository or project name, so GitLab is within it. Bloom says npm's GitLab integration had the same weakness.	Any independent test of GitLab. CircleCI, the third provider in npm's documentation, is not mentioned by Bloom.

Interests, one line each. Bloom sells endpoint security that covers AI agents and third-party code, so a finding that ties agents to package risk fits its product. GitHub owns npm and marks its own work, and its changelog does not mention a report. The Next Web article carries a contributed-article label, not newsroom reporting. Cyberpress repeats Bloom's account, and Security Boulevard's page refused the request and was not read. Method is separate from accusation: the four months of delay is Bloom's account, and GitHub's statement, as reported, neither disputes nor addresses the timeline. Both sides say a fix exists.

The dates, the downloads and the 100-clone rule, worked through

The disclosure timeline. Dates are Bloom's account unless the row says otherwise; the day counts are derived from them.

Event	Date (2026)	Days after report (derived)
Bloom reports through GitHub's HackerOne programme	6 June	0
GitHub validates (Bloom's account, no GitHub date)	9 June	3
Last reply to Bloom before the fix	8 July	32
Six follow-ups, one a mediation request, unanswered	After 8 July, dates not stated	Not stated
GitHub changelog post announces the fix (GitHub)	2 October	118
Bloom publishes; Help Net Security reports	13 October	129

From the last reply to the fix is 86 days (derived), and to Bloom's publication 97 days (derived). The fix is dated 11 days before Bloom published (derived). Bloom says it re-ran its own test before publishing and found a fix had been made, and that GitHub's team then replied to its final enquiry, apologised for the lack of communication and confirmed it. No date is given for that reply. Bloom's summary box says "over 120 days" from disclosure to fix, and The Next Web repeats it. The dates Bloom gives are 118 days apart (derived), so the wording runs slightly ahead of them. Trusted Publishing itself became generally available on 31 July 2025, 428 days before the fix (derived).

Downloads. Ten million downloads over 1,500 packages is about 6,700 per package in total, and a million a month is about 670 per package per month (both derived, rounded). Help Net Security reaches the same order, "several hundred" a month. Three cautions. Both Bloom figures are "more than", so the ratio is not a bound in either direction. The period behind the total is not stated. And an average hides the distribution: a few widely used packages and a long tail of abandoned ones give the same mean. Help Net Security's own point is that one hijacked package is enough. A package whose repository or owner has vanished may be less actively maintained than the average (inference); if so, the typical exposure is smaller and the worst case is unchanged.

Adoption. No count from npm or GitHub of packages using Trusted Publishing was found. Bloom writes that adoption is "under 20% of active packages", an estimate with no method. Aikido, a security vendor, wrote on 24 August 2026 that 11,001 of the top 51,370 npm packages had adopted Trusted Publishing, which is 21.4 per cent (derived), without saying how top was ranked. The two are different populations. The exposed share of packages using the feature cannot be computed, and this briefing does not divide 1,500 by either figure.

The 100-clone rule. What it protected is not stated as a number. Bloom's researcher told Help Net Security that Bloom took the rule into account and that everything it counted as vulnerable was a claimable name. That implies retired names sit outside the 1,500 (inference from that statement). How many packages the rule kept out of the count is not stated, and neither is how Bloom decided a name was claimable.

The AI agent multiplier is Bloom's telemetry, and its figures do not reconcile

Bloom's argument is that coding agents carry a flawed publishing link further, because they pick, install and run dependencies without a person reading a maintainer's name. It supports that with telemetry from dozens of organisations: each agent brings in new packages at 0.3 to 1.2 a day, a typical endpoint runs three agents and picks up about 70 agent-installed packages a month, and a developer machine runs five or more and picks up close to 350, direct installs only. Bloom also says that a few weeks ago it caught and blocked a customer's agent trying to install one of the affected packages.

Three checks. First, the arithmetic. Three agents at 0.3 to 1.2 a day is 27 to 108 a month (derived, 30 day month), which contains 70. Bloom's body text gives 2 to 3 a day on developer machines, which is 60 to 90 a month (derived), and five agents at the same rates give 45 to 180. Neither reaches 350, which is about 11.7 a day (derived). Bloom does not reconcile them. Second, the unit: Bloom's summary says the average agent installs 70 a month, and its body says an endpoint does. This briefing uses the body, as Help Net Security does. Third, what the caught install shows: an agent tried to install a package whose name was claimable. Bloom does not say that package was malicious, hijacked, or ever published through a reclaimed name.

None of this is evidence that an agent installed a hijacked release, and Bloom does not claim it. It is a plausible multiplier, from one vendor's customer base, on a risk that no source says was exploited. The practical point stands without it: any install path that takes the newest version without review is exposed to any hijack, whatever the cause.

What GitHub changed, what it did not say, and what a maintainer must now do

GitHub's changelog post of 2 October 2026 says that unvalidated npm Trusted Publishing configurations "expire 48 hours after creation and can no longer authorize publishing". A first successful publish validates the configuration and exempts it from expiry. Changing the repository or project identity needs a new trust relationship and a fresh 48 hours, and ordinary edits do not restart the clock. An expired configuration stays visible, does not count toward the per-package limit, and has to be recreated. npm's documentation, last edited on 6 October, says the same in terms of two days, and says an expired configuration "can no longer be used or edited".

Read plainly, this shrinks the window and does not remove the comparison. Before, a binding that never published stayed open to a reclaimed name for as long as it existed. Now it is open for at most 48 hours, then dead. Neither the post nor the documentation says that npm now resolves the repository's numeric ID when a binding is created, which is the check Bloom recommends. npm's page adds that npm does not verify a configuration when it is saved. So after the change the model is a decision at first use: the repository that publishes first within 48 hours is the one whose identity is bound (inference from the documentation, not a statement by either party). For a maintainer who publishes promptly that is the right repository. For one who creates a binding and waits, the binding dies.

Three things are not stated. Whether bindings created before 2 October and never published were expired, and if so when and how many. Whether Bloom's count of 1,500 fell as a result. And why Bloom, writing after the fix, still gave "still prevalent" as its reason for withholding the list. The changelog has no migration note, and npm's page describes only newly created configurations. Help Net Security notes that GitHub's statement does not say whether configurations that had already published were bound retroactively. Bloom's description and npm's page both put the binding at the first publish, so a configuration that had published was already bound (inference); the open case is the one that never published.

The same changelog post carries a second change that it does not describe as related: npm now rejects Trusted Publishing tokens from GitHub Actions issue comment events, alongside an existing restriction on pull request target events. Both are described only as event types a workflow can no longer publish from, and neither is part of Bloom's finding.

npm's documentation also describes controls that bear on this class of flaw and existed before the fix. Configurations created before 20 May 2026 are set to allow direct publishing only, and newer ones can be made stage only, so that a maintainer approves each release with two-factor authentication. A package can be set to disallow tokens, and a protected environment with required approvers can gate the workflow. A configuration cannot be edited, so moving to stage only means deleting and recreating it, which starts a new 48 hours. Direct publishing by two-factor-bypass tokens is due to end around January 2027, per GitHub's July post and npm's roadmap discussion. That will push more maintainers toward Trusted Publishing, so more bindings will be created.

Four friendly names and what each one proves

A label is not a control. Each of these four sounds like one. Each is true of something narrower than it suggests.

Labels in the story, where each appears, and what the record shows.

The label	Where it appears	What the record shows
Trusted publishing	npm's name for the feature. GitHub's 31 July 2025 announcement said npm would accept publishes only from the workflow a maintainer authorised.	The trust was in a repository name and a workflow file name. Until a first publish, no immutable identifier was behind it. PyPI's page says to "treat your Trusted Publishers as if they are API tokens".
Provenance attestation	npm's documentation: it lets users "publicly establish where a package was built and who published a package".	A release published through a reclaimed name carries a valid attestation naming the other repository (Bloom). npm's page says provenance "does not guarantee" a package has no malicious code. It attests where a build ran, not whose package it is.
No long-lived tokens	npm's documentation and GitHub's 2025 announcement.	The credential disappears and the binding remains. A binding is a standing permission. Bloom notes that nothing of the maintainer's was touched, which is the point: there was nothing to steal.
Validated, and verified	Validated is GitHub's word for a configuration after its first publish. npm's audit command verifies registry signatures and attestations.	Validated means it has published once. Verified means signatures check out. Neither says the repository named is the one you expect, and the pages read describe no comparison with an expected repository.

This site has seen the provenance and trusted publisher labels fail as controls before. In its briefing on a malicious npm release that was live for about 102 minutes, the registry's attestation was real and named the project's own workflow: it described where the build ran, not whether anyone had reviewed it. A different mechanism, the same lesson: a label that records an origin is not a control that stops a bad change.

Other registries: only what their own pages say

Bloom says npm's GitLab integration had the same weakness and that PyPI's Warehouse already stores the IDs. The table gives what each registry's own page says, read on 13 October 2026. No registry was tested for this briefing, and nothing here is a statement that another registry is or is not exposed.

What each registry's own documentation says about identifiers and resurrected names. Pages read on 13 October 2026.

Registry	What its page says	Not stated
PyPI	For GitHub it checks the owner ID claim: it looks up the configured username's ID when the publisher is configured and stores it, against account resurrection. For GitLab it says that if a user or group is deleted and a new one has the same name, tokens from the new one are still recognised.	Whether it also stores the repository ID. Bloom says PyPI implements precisely this pattern; the page read names the owner ID.
RubyGems	The guide asks for owner name, repository name and workflow name. A pending publisher for a new gem becomes a normal one after the first successful push.	Any use of numeric IDs, or what is stored at the pending stage. The page links to PyPI's pages for how it works.
crates.io	Its page lists owner, repository name, workflow filename and an optional environment, and says the crate must already be published. It claims repository and workflow verification. The text of RFC 3691 was also searched.	Any mention of numeric IDs or renamed owners, on the page or in the RFC text searched.
npm: GitLab and CircleCI	GitHub's post covers a repository or project name. npm's documentation lists CircleCI as a third provider, with organisation, project and pipeline IDs in UUID format.	Whether CircleCI was in scope of Bloom's work. Bloom does not mention it.

The UK: what the NCSC says, what Cyber Essentials does not, and the ICO

The nearest UK statement is the NCSC's blog Software supply chain attacks: check your dependencies, published on 4 June 2026 for cyber security professionals. It names the May 2026 Mini Shai-hulud wave, lists the techniques seen (maintainer account compromise, abandoned package takeover, typosquatting and self-propagation) and recommends reviewing how dependencies are introduced and updated. Its abandoned package takeover covers expired maintainer domains and transfers of ownership. A claimable repository name is a close relative, but the blog does not mention Trusted Publishing or provenance, and it predates Bloom's finding.

UK guidance and law as read on 13 October 2026 from the pages cited, and where each stops. Quotations are short and exact.

UK source	What it says	Where it stops
NCSC blog, 4 June 2026	Not to adopt new dependency versions automatically without review. Deploy through controlled pipelines, keep credentials off developer workstations, enforce multi-factor authentication for developer and registry accounts, use private or trusted registries where appropriate, keep an inventory such as an SBOM.	No mention of lockfiles, pinning, a cooldown period, install script settings or Trusted Publishing, as read. Advice for defenders, not a duty.
NCSC, secure the build and deployment pipeline (published 2019)	Principle 9: be cautious of importing third party libraries and their updates, and ensure only intended dependencies come from legitimate sources. Principle 5: manage secrets with care. Principle 6: controls cannot be bypassed.	Predates OIDC publishing. Says nothing about how a registry decides who may publish.
Software Security Code of Practice, updated 15 January 2026	1.2: assess the risks of third-party components. 2.1 and 2.2: protect and control changes to the build environment. 4.3: tell customers about notable incidents. Open-source developers and maintainers are "not considered the primary audience", and risks in open-source code are for end users or proprietary developers using it to manage.	Voluntary. Aimed at suppliers selling to business customers. Does not tell a maintainer what to audit.
Cyber Essentials requirements v3.3, April 2026	Software includes libraries. All in-scope software must be kept up to date, with "automatic updates enabled where possible", and updates that fix critical, high or unrated vulnerabilities applied within 14 days of release. Bespoke and custom parts of web applications are out of scope.	The words supply chain, package, npm, open source, repository and pipeline do not appear. The rule is about vendor fixes. It does not address whether a new release should be trusted.
ICO, personal data breaches guide	Report a notifiable breach to the ICO within 72 hours of becoming aware, where feasible, and tell affected people without undue delay if the risk to them is high.	Triggered by a breach of personal data, not by a flaw. A claimable name is not a breach.

Cyber Essentials and the NCSC pull in different directions for a team that auto-updates its dependencies. They are not contradictory, because they concern different things (a reading, not a statement in either document). Cyber Essentials asks for automatic updates of supported software so that vendor security fixes land within 14 days. The NCSC asks that new dependency versions are not adopted automatically without review. A hijacked release arrives as an update. A certified organisation can meet every Cyber Essentials requirement and still adopt it within the hour (reading).

A UK company that publishes open source. The Code of Practice says maintainers are not its primary audience, and no UK instrument read requires a maintainer to audit publisher bindings. The duty is practical and cheap: one list per package. If the same company sells software built on those packages to business customers, the Code, which the Government describes as relevant to any software supplied to business customers, would put principles 2.1, 2.2 and 4.3 on what it sells. A UK company that installs npm packages. If a malicious release ran on your build or developer systems and personal data left, you are dealing with a personal data breach under the ICO's guide, with the 72 hour clock running from awareness. Nothing read makes an organisation answerable for a registry's own binding rules, and nothing reads as a standard for how old a release must be before you adopt it.

What to do, in the order worth doing

Maintainers first, because the exposure sits in their settings, then consumers. Every item is a control that npm, PyPI, the NCSC or Bloom already names. None needs a model or a test result to justify it.

If you find a suspect version already installed, treat the machine or runner as compromised and follow the incident steps in this site's earlier briefing on a malicious npm release. A claimable name is a reason to look, not evidence that anything was published.

What could not be verified

• Real-world abuse. None reported in any source read. Bloom's work is a controlled demonstration.
• The 1,500. Bloom's own scan. No list, date, method, or confirmation that each counted binding had never published.
• Dates and the apology. Validation, the last reply, the six follow-ups and the apology are Bloom's account. GitHub gave no dates. The HackerOne report was not found public.
• GitHub's statement. Read only as printed by Help Net Security. No GitHub page carrying it was found.
• Pages not read. Security Boulevard refused the request and was not read, and no bypass was tried. NewsBlaze and a C# Corner article were opened and gave nothing beyond Bloom's account or no specifics, and are not relied on.
• Other registries. Only their own pages were read, and nothing was tested. crates.io's page loads by script and was read in a browser; the RFC text searched does not address identifiers.
• GitHub's retirement rule for repository deletion and account deletion: not found on the pages read.
• Older never-published bindings. Whether they were expired is not stated by any source.
• Time-stamped. Sources were read between 11:17 and 11:40 BST on 13 October 2026. Bloom's page, GitHub's changelog and npm's documentation can change within hours; npm's trusted publishing page was last edited on 6 October.

The question that exposes the gap

For each npm package your build installs, can you say which repository its next release must come from, and what in your pipeline would refuse a release that came from a different one?

Key facts