GitLab and npm attacks that skip credential theft both start with a repository the attacker creates

Where "no login" stops on the GitLab side

GitLab scores CVE-2026-97229 at CVSS 10.0, with a vector that sets privileges required and user interaction to none ^[2]. The advisory says that "under certain conditions" an unauthenticated user could run arbitrary code on the GitLab server through a crafted regular expression in a CI/CD configuration ^[3]. Shane Barney, chief information security officer at Keeper Security, took the vector at face value. He said exploitation requires no authentication and no user interaction ^[18].

Rapid7 reproduced the exploit and found a step the score leaves out. The attacker needs a way to plant a malicious CI/CD configuration in a repository before triggering the bug ^[4]. In Rapid7's test that meant committing a .gitlab-ci.yml file and a repository path containing UTF-8 characters to a branch in a public project ^[5]. An ordinary account can do that by creating a public project, where the instance permits it ^[5]. On instances where new users can self-register and create projects, Rapid7 said, the constraint is removed ^[4]. Orca states the open condition more broadly: no authentication is needed where an instance allows public project creation or user self-registration ^[13].

In our view, exposure is set by each instance's sign-up and project policy. A server with open registration lets anyone satisfy the prerequisite ^[4]. A closed one needs an attacker who already holds an account that can create or write to a public project ^[5]. "No login" is accurate for the first case and an overstatement for the second.

What the exploit does once it runs

The flaw is an ordering problem. The crafted expression first compiles in a compact US-ASCII form and passes GitLab's regular expression validation ^[6]. When it is evaluated against a specially formed, valid UTF-8 repository path, Ruby's Onigmo engine recompiles it for the new encoding after those checks have completed ^[6]. An integer overflow in the program-size calculation then generates invalid instructions, and the resulting loss of control-flow integrity lets attacker-controlled Onigmo VM operations run an operating system command as the GitLab git user ^[6].

Rapid7 validated the chain against the official GitLab 19.4.1 CE Linux amd64 image with address space layout randomization enabled ^[7]. The same input did not execute against the patched 19.4.2 image ^[7].

Rapid7's description of the exploit reaches a command running as the git user ^[6]. The step from there to secrets comes from other analysts. Roman Sannikov of iCounter said a self-managed GitLab server holds source code, build pipelines and usually the credentials those pipelines use to reach cloud accounts, package registries and production ^[15]. A second fix in the same release touches the same material. CVE-2026-14814, rated CVSS 8.2, let a user poison cached responses for raw repository files, so targeted users' pipelines would run crafted content and could expose protected environment variables ^[19].

No source reports secrets taken from a live instance. Rapid7 reported no confirmed exploitation in the wild as of its October 13 post ^[8].

The clock and the cost

GitLab shipped 19.4.2, 19.3.5 and 19.2.8 on October 12 ^[1]. Rapid7 published its reproduction the next day ^[8]. GitLab's previous maximum-severity flaw, CVE-2026-85706, drew in-the-wild probing within hours of disclosure and was later added to CISA's KEV catalog, according to Orca ^[10]. Sannikov said "Teams should assume the window between disclosure and exploitation is days, not weeks," and pointed to scanning that began shortly after disclosure of that earlier flaw ^[16].

GitLab's issue tracker publishes details of security fixes 90 days after the release that patched them ^[20]. For this release that date is January 10, 2027 ^[40]. Rapid7 said its root-cause and exploit-chain detail will come in a separate technical analysis ^[9].

The fix is the upgrade. The affected range is every version from 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2 ^[1]. GitLab.com is already patched and GitLab Dedicated customers need take no action ^[11]. For them this flaw does not matter.

Self-managed teams who cannot upgrade today have partial options. Orca says GitLab has published no workaround and recommends disabling user self-registration where it is not needed ^[14]. Rapid7 lists restricting anonymous access to public projects and keeping untrusted users from creating or writing to them, and says those controls cover only the demonstrated delivery path and do not fix the compiler ^[12]. After patching, Sannikov advised looking at what a compromised instance could have reached, rotating CI/CD secrets and tokens, and reviewing runner and pipeline activity since disclosure ^[17].

The npm side: trusting a name

Bloom Security found that npm's Trusted Publishing let an attacker push new versions of someone else's package without stealing a credential ^[21]. The attacker only had to register a GitHub repository name that the maintainer had left behind ^[21]. Bloom counted more than 1,500 exposed packages with more than 10 million downloads in total and more than a million a month ^[22].

The cause is what npm recorded when a maintainer set up a trusted publisher. It stored the repository by its owner/repo name, the slug. GitHub puts permanent numeric IDs for the repository and owner in the identity token it issues, and npm did not check them ^[23]. Golan Myers, a security researcher at Bloom, described it this way: "It is like a lock that checks the address on the door rather than who owns the house: when the owner moves out, whoever moves in gets the key." ^[25]

Two conditions limit the attack. The victim's trusted publisher has to point at a slug an attacker can claim, and the repository must never have been used to publish a version of the package ^[24]. Given both, the attacker creates a repository at the freed slug, which gets a fresh numeric ID, then triggers a publish workflow that mints a token carrying the reclaimed slug and the new ID. npm matches the slug and issues a time-limited publish credential for a package the attacker does not own ^[24]. Bloom ran this end to end on a package and repositories its researchers controlled ^[38].

GitHub already retires the names of repositories with more than 100 clones in the week before an owner account is renamed or deleted ^[27]. That protects some packages. "We took this into account. Everything we considered vulnerable was pertaining to claimable slugs," said Myers ^[27].

A malicious release can carry a postinstall hook, and its code can run during installation on developer machines or continuous integration systems ^[33]. The release also carries a valid provenance attestation, a signed build record, and it names the attacker's repository ^[26]. A consumer who checks only that an attestation exists would find one. Bloom advises checking that the attestation names the repository the project is supposed to come from, and it is not publishing the affected package names, so there is no list to check against ^[36].

Bloom argues that AI coding agents widen the reach. From telemetry across dozens of organizations, it estimates that agents on a typical endpoint install about 70 packages a month and close to 350 on developer machines, excluding dependencies, usually without a review of the package or its maintainer ^[37]. Both figures are Bloom's own.

How fast GitHub moved, and what it left open

Bloom reported the flaw through GitHub's HackerOne bug bounty program on June 6, and GitHub validated it on June 9 ^[28]. Bloom says GitHub's last reply came on July 8 and that six follow-ups, including a mediation request to HackerOne, went unanswered ^[29]. GitHub announced its change on October 2 ^[30]. From report to announcement is 118 days ^[39].

The change expires unvalidated trusted publishing configurations 48 hours after creation. A configuration becomes exempt after its first successful publish, and changing the repository or project identity requires a new trust relationship with a fresh 48-hour window ^[31]. That targets the exposed population, since the slug swap only works against a binding that has never published ^[24]. GitHub's statement does not say whether configurations that published before the change were bound retroactively ^[30].

Maintainers can run npm trust list and confirm each listed repository still resolves to one they control. They should delete and re-create any binding that points at a renamed or transferred repository, and remove a binding before deleting a repository ^[35].

Where the two meet

Both attacks skip credential theft, and both begin when the attacker creates a repository: a public project on a GitLab instance, or a repository at a freed name on GitHub ^[5][24]. Both end in the build pipeline. On the GitLab side that is the server that, per Sannikov, holds pipeline credentials ^[15]. On the npm side it is the developer machines and CI systems that run a malicious postinstall hook ^[33].

There is also a direct link. Bloom says npm's GitLab trusted publishing integration has the same weakness ^[34]. GitHub's description of the fix refers to repository or project identity ^[31], and the sources do not say whether GitLab-side bindings were changed.

The two differ in what is known. GitLab's flaw has a patch, a lab reproduction and no confirmed exploitation as of October 13 ^[8]. The npm flaw has a fix and a controlled demonstration, and Myers said it is unknown whether anyone exploited it in the wild ^[32].