Over 11,000 GitLab instances unpatched: two CVSS 10 flaws from October and what operators should check

GitLab closed the two flaws with patch releases on 12 and 21 October 2026. (Quelle: Wikimedia Commons, file GitLab logo.svg, MIT license, GitLab)

According to BleepingComputer and Techzine, the Shadowserver Foundation counts more than 11,300 GitLab instances that are vulnerable to CVE-2026-110264, out of about 39,000 GitLab instances it sees every day. On 3 November Golem ran a story headlined "Dringend patchen: 11.000 Gitlab-Instanzen durch laufende Angriffe gefährdet" (patch urgently: 11,000 GitLab instances at risk from ongoing attacks). Behind it are two flaws rated CVSS 10.0 that GitLab fixed on 12 and 21 October. We measured nothing ourselves. We read the GitLab advisories, the Ruby notice, the CISA catalog and the report from Alpine Linux. Of the Golem story we could read only the teaser, the rest sits behind a cookie prompt.

A CVSS score of 10.0 means the vendor rates a flaw as reachable over the network, without privileges and without user interaction, with full impact on confidentiality, integrity and availability, and with effects beyond the application itself. The score describes severity under those assumptions. It does not say how easily an attack succeeds on a given installation.

The flaws with versions

The first two rows are the October flaws. The third is there for comparison: GitLab had already shipped a CVSS 10.0 fix in September.

CVE	CVSS	Affected versions	Fixed versions	Source	Date
CVE-2026-97229	10.0	19.2 before 19.2.8, 19.3 before 19.3.5, 19.4 before 19.4.2	19.2.8, 19.3.5, 19.4.2	GitLab patch release	2026-10-12
CVE-2026-110264	10.0	all versions from 7.0 before 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1 (depending on the line)	18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, 19.5.1	GitLab patch release	2026-10-21
CVE-2026-85706	10.0	18.7 before 18.11.12, 19.0 before 19.0.9, 19.1 before 19.1.8, 19.2 before 19.2.6, 19.3 before 19.3.2	18.11.12, 19.0.9, 19.1.8, 19.2.6, 19.3.2	GitLab patch release	2026-09-10

All three scores come from GitLab itself. For the two October flaws the vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: network attack, low complexity, no privileges, no user interaction. For CVE-2026-97229 Rapid7 describes conditions behind "unauthenticated": the attacker must be able to place a CI configuration in a repository, which according to Rapid7 takes an ordinary account where accounts may create public projects, and not even that where self-registration is open. The exploit chain is in our post of 16 October on npm and GitLab. For CVE-2026-110264 we found no independent analysis of the attack conditions. Ruby writes that the bugs are reached only when an application compiles a regular expression from characters an attacker controls.

CVE-2026-85706 is a path traversal in the commits API and has been in the CISA catalog since 11 September. It is unrelated to the two regex flaws.

Why an update is not just an update

The versions from 12 October fix only CVE-2026-97229. For the second flaw, 19.4.2 sits below the fix 19.4.3, so anyone who updated then is back in the affected range.

The fix has a quirk too. According to GitLab it is a patch to Ruby that GitLab applies only in its official Linux packages and container images. Anyone running GitLab from source or in their own image with their own Ruby needs Ruby 3.3.13, 3.4.12 or 4.0.9 on top. Ruby released those versions on 23 October and names four GitLab CVEs fixed in them: CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264.

Alpine Linux described how this played out on 28 October. A newly registered account sent crafted CI configurations to its instance on 20 and 21 October, when the instance was still on 19.3.4. The workers crashed eight times, and in four cases the attacker got one step further. The upgrade to 19.3.6 on 22 October did not help, because the image contained a standard Ruby without GitLab's patch. Alpine found no evidence of executed code but could not rule it out, and rebuilt the instance from scratch.

Who counted the 11,000

Counter	Number	As of	What is counted
Shadowserver	over 11,300 vulnerable to CVE-2026-110264, over 1,000 to CVE-2026-97229, out of about 39,000 GitLab instances seen daily	post of Sunday 2026-11-01, reported on 2 November	method not described in the reports we read; operators get IP lists in the "Vulnerable HTTP" report
Censys	81,820 hosts with GitLab software	2026-10-21	search query for GitLab as software, all versions treated as potentially affected

Both numbers are statements by the counting organisations, and we did not re-measure either. They do not contradict each other because they count different things: Censys counts every host with GitLab software, Shadowserver the instances it sees daily and the vulnerable ones among them. The share of almost 30 percent is in the Techzine report, and Golem's teaser says "almost every third". Inference, unmeasured: a scan from outside can hardly see whether the Ruby in an installation is patched. An instance with a matching GitLab version and an unpatched Ruby, as at Alpine, would then be classed wrongly.

What is documented about exploitation

CISA has listed CVE-2026-97229 as exploited since 29 October, with a due date of 1 November. The ransomware field reads "Unknown". CVE-2026-110264 is absent from the catalog we fetched on 9 November (file state: 6 November). Censys knew of no exploitation on 22 October, and BleepingComputer wrote on 2 November that it was not confirmed. Our reading: "ongoing attacks" in the Golem headline refers to CVE-2026-97229, while the 11,300 belong to CVE-2026-110264. That is an inference from the teaser and the sources, we did not read the Golem text.

Our status

We run Gitea for our repositories and no GitLab. Our host inventory has no entry for GitLab and none for GitLab Runner. The only hit in the documentation is a link to the upstream project gitlab.com/kyber in an RFC. That is an inventory finding. We did not scan the hosts for GitLab containers, so there is no network measurement behind it. The advisories name CE and EE as affected and do not list a runner.

What operators should check now

Determine the version and move to the fix for your line: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. For instances reachable from the internet, do it this week, not in the next regular maintenance window.
With your own Ruby or image, check that it contains Ruby 3.3.13, 3.4.12 or 4.0.9. For its alpinelinux/gitlab image Alpine writes that any 19.3.6 pulled before 27 October and all older tags are vulnerable.
Go through the logs from 12 October for crashed workers. GitLab publishes detection rules for this, such as "Onigmo native worker crash" and "Org mode render error burst".
If there are signs of executed code, treat the instance as compromised and rotate what Alpine lists: gitlab-secrets.json, CI/CD variables, runner tokens and access tokens.
Shrink the attack surface: switch off self-registration and anonymous access to public projects, and put the instance behind a VPN or IP filter where it does not need to be public.

More posts on supply chains and patch levels are collected in the hub Security and privacy. Anyone who wants to know which Git services, containers and versions run in their own network will find the offer under Services.