Supply chain in practice: npm trusted a repository name, and GitLab trips over a regular expression

In the week of 12 October 2026 two reports appeared that look unrelated at first: a flaw in the trust check of npm Trusted Publishing, and a hole rated at the top score CVSS 10.0 in the CI/CD part of GitLab. Both hit the same spot, namely what a pipeline believes about a repository. This post rests on the sources below. We made no measurements of our own for it.

npm is the package registry from which our web projects also pull their dependencies. (Quelle: Wikimedia Commons, file Npm-logo.svg, public domain, npm, Inc.)

npm: the name became free and the right went with it

Trusted Publishing lets you publish packages without a stored access token: the registry trusts a workflow in a particular GitHub repository. Bloom Security found that npm tied that repository by the name in the form owner/repository and the name of the workflow file, and not by the permanent numeric ID that GitHub assigns. If a repository was renamed, transferred or deleted, or an account renamed or deleted, the old name was free. An attacker created it anew, added a matching workflow file and received a valid publish token for a package that was not theirs. They needed no stolen credentials for it.

By Bloom, more than 1,500 packages with over 10 million downloads in total were exposed, over one million a month. One package alone had more than 200,000 monthly downloads. Bloom used the flaw in a controlled test to publish a new version of an existing package, and did not observe exploitation in the wild. Bloom does not publish the package names.

Five steps after Bloom Security and CSO Online. Checking the numeric ID would have prevented the fourth step. (Quelle: Help Net Security and CSO Online, 13 Oct 2026)

On the timeline: Bloom reported the flaw, according to Help Net Security, on 6 June 2026 through GitHub's HackerOne programme, GitHub validated it on 9 June, and Bloom writes that several follow-ups went unanswered afterwards. On 2 October GitHub announced the correction: unvalidated Trusted Publishing configurations expire 48 hours after creation and can then no longer authorise publishing. A configuration counts as validated after its first successful publish. npm also now rejects tokens issued through issue_comment events in GitHub Actions. CSO Online points out that the fix closes the danger from unvalidated configurations, but maintainers still have to review their existing trust relationships themselves. Whether configurations bound before the change are protected retroactively, the source does not say.

Bloom states that AI agents install about 70 packages per endpoint and month, and around 350 on developer machines, not counting transitive dependencies. That is a vendor statement with no independent check.

GitLab: a number overflows

CVE-2026-97229 is an integer overflow in the regular-expression compiler of GitLab's CI/CD part, rated CVSS 10.0. Rapid7 describes the chain: a crafted expression passes the check while it is compiled as US-ASCII. When it is later evaluated against a repository path with UTF-8 characters, Ruby's Onigmo engine recompiles it, and an overflow in the program-size calculation produces invalid instructions. The result is execution of an operating-system command as the user git. Rapid7 reproduced the chain on GitLab 19.4.1 CE with ASLR active and found that the same input does not execute on 19.4.2.

The flaw is fixed in 19.2.8, 19.3.5 and 19.4.2 of 12 October 2026. Self-managed instances are affected, GitLab.com is already updated, and GitLab Dedicated customers need to do nothing. heise counts 24 closed flaws in the same release, and its description rests on six, one of them critical.

To put the rating "without login" in context: according to Rapid7 the attacker has to place a .gitlab-ci.yml in a repository and use a path with UTF-8 characters. Where ordinary accounts may create public projects, one account is enough, and with open self-registration even that falls away. Rapid7 published a proof of concept on GitHub and updated its post on 16 October. Exploitation in the wild is not confirmed according to Rapid7. Until the update Rapid7 recommends limiting anonymous access to public projects and forbidding untrusted users to create or write to public projects. That does not fix the bug but reduces the attack surface.

Self-managed GitLab instances are affected by CVE-2026-97229, while GitLab.com is already updated. (Quelle: Wikimedia Commons, file GitLab logo.svg, licence MIT, GitLab)

How long the corrections took

Our own calculation from the sources' dates: Bloom reported on 6 June and GitHub announced the fix on 2 October. For the curl advisory, 29 days lie between the report on 15 September and the release on 14 October. For GitLab the sources give no report date. (Quelle: Help Net Security (npm), curl advisory CVE-2026-92392)

What both cases have in common

In both cases a string from the repository decides what a pipeline may do. For npm it is the name, for GitLab the expression in the configuration file. In both cases the fault lay in the platform and not in the operator's work. And in both cases a task remains after the fix which the platform does not take off the operator: checking existing bindings.

What operators check

npm maintainers: run npm trust list and check that every listed repository still belongs to one you control. Delete and recreate bindings that point to renamed or transferred repositories. Remove the binding before deleting a repository. That is Bloom's recommendation.
npm users: check in a package's provenance statement that the named repository belongs to the project. Anyone building software for customers also defines what developers and AI agents may install (Bloom's recommendation).
GitLab operators: check the version, update to 19.2.8, 19.3.5 or 19.4.2 and limit the creation of public projects until then.
Anyone running another platform for Git and CI, for example Gitea, looks there for the same class: where does a string set by the user decide the pipeline's rights? The sources contain no statement on that for Gitea.

What forums say

We searched Hacker News and found no submission on either case (search on 16 October 2026). noted.lol, a blog for self-hosted software, covers the GitLab topic with a summary.

How we checked

On 16 October 2026 we read the Help Net Security and CSO Online reports on npm, Rapid7's post on GitLab (as of 16 October) and the heise report. The sources differ: Help Net Security gives 2 October for the npm fix, while another report dates GitHub's tightened rules to 13 October. We follow 2 October, which CSO Online attributes to the npm team and links to the GitHub changelog. The affected GitLab versions were also stated differently in the reports. Rapid7, Help Net Security and heise name 19.2.8, 19.3.5 and 19.4.2 as fixes, and we did not read GitLab's own advisory.