Last week's GitLab headline was that over 1,000 servers were still exposed to a remote code execution flaw under active attack. That is true. It is also the smaller of the two numbers in the post the headline came from.

The Shadowserver Foundation published both on 1 November. The first is the one that got written up: over 1,000 instances vulnerable to CVE-2026-97229, added to the CISA catalogue of known exploited vulnerabilities on 29 October. The second, in the same post, is over 11,300 instances vulnerable to CVE-2026-110264, out of roughly 39,000 GitLab instances Shadowserver sees daily.

Eleven times as many. Twenty-nine percent of every GitLab instance on the internet. And CVE-2026-110264 is rated CVSS 10.0.

Why the second number is bigger

Not because people ignored it. Because of the order the patches shipped in.

12 October. GitLab releases 19.4.2, 19.3.5 and 19.2.8, fixing CVE-2026-97229.

21 October. GitLab releases 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, fixing CVE-2026-110264, the 10.0.

29 October. CISA adds CVE-2026-97229 to the exploited catalogue, with a federal deadline.

Follow an administrator through that. The alarm arrives on 29 October about the October 12 bug. They patch to the version that fixes it. If the version they reach for is 19.4.2 or 19.3.5 or 19.2.8 then they have patched the exploited bug and left the 10.0 completely open, because the releases that fix it came nine days later.

For those nine days, 19.4.2 was the newest thing there was. The deadline pulled a large number of installations onto a release that was already short, and the exposure counts are what that looks like from the outside.

The fix is not in GitLab

Here is the sentence from GitLab's own patch page, and it is unusual enough to quote exactly:

"The fix for CVE-2026-110264 is a patch to Ruby, not to GitLab code, and it is only included in official GitLab Linux packages and container images."

The bug is an integer overflow in Onigmo, the regular expression engine built into Ruby, reached when GitLab compiles a regular expression that a user supplied. GitLab ships its own Ruby inside its packages, so GitLab patched the engine there.

Which means the upgrade instruction has a second half that most upgrade instructions do not have. From the same page: if your installation uses its own Ruby runtime rather than the bundled one, for example a self-compiled installation or a custom container image, "upgrading GitLab is not sufficient: you must also upgrade Ruby to 3.3.13, 3.4.12, 4.0.9 or later".

Anyone who builds GitLab from source, or maintains a hardened image with its own Ruby layer, can upgrade GitLab to the newest release, see the version number they were told to reach, and still be running the vulnerable engine. There is no version check that catches this, because the version that matters is not GitLab's.

A detail worth keeping

GitLab patched its bundled Ruby on 21 October. Upstream Ruby published 3.3.13, 3.4.12 and 4.0.9 on 23 October.

GitLab shipped the fix for a Ruby bug two days before Ruby did. That is a reasonable thing for a vendor to do when it controls its own runtime, and it is also exactly why the source-build caveat exists. For two days the only patched Ruby in the world was the one inside GitLab's packages.

How far back it goes

The affected range on GitLab's page runs from 7.0 up to the patched releases. GitLab 7.0 shipped in 2014. That is roughly twelve and a half years of releases carrying the bug.

The credit goes to joaxcar, reporting through HackerOne.

One observation, offered as nothing more

While checking something unrelated we read musl libc's commit log. Its most recent commit, dated 14 October 2026, is titled "regex: avoid int overflow in regcomp".

An integer overflow in a regular expression compiler. Two days after GitLab's first regex fix, a week before the Onigmo one, in a completely different library written in a different language by different people.

We are not claiming a connection. We looked for one and did not find it. But three regular expression compilers receiving integer overflow fixes inside one fortnight is the sort of pattern that usually means somebody has pointed a new tool at an old problem, and if that is what happened then the interesting question is which compiler is next.

What to do

  • Check your actual version against the 21 October list, not the 12 October one. The releases are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13.
  • If your installation builds or installs its own Ruby, check the Ruby version separately. It needs to be 3.3.13, 3.4.12, 4.0.9 or later.
  • GitLab.com runs a patched version and GitLab Dedicated customers need no action. This is a self-managed problem.
  • If you patched in the last week of October because of the catalogue deadline, you are in the population this article is about. Check again.

What is not established

  • Whether the musl commit and the Onigmo bugs share a researcher, a tool, or anything else. We found no link, and the absence of a link is not a denial of one.
  • Whether CVE-2026-110264 has been exploited. Reporting says no confirmed exploitation, and it is not in the exploited catalogue. The one under attack is the other one.
  • How many of the 11,300 are source installations that will remain vulnerable after a GitLab upgrade. Shadowserver counts instances, not build methods.
  • Whether the exposure counts have moved since 1 November. They are a week old.