DampSnag

Patch Your GitLab Again: CVE-2026-110264 Is a 10.0, and Your October Update Didn't Cover It

#gitlab #security #self-hosting #homelab #devops

GitLab just fixed an unauthenticated remote code execution bug that goes all the way back to version 7.0. If you self-host, including if you patched on 12 October, here's what it is, how to check your version, the exact upgrade to grab, and what to look for in your logs.

If you run your own GitLab, stop what you're doing and check your version. On 21 October GitLab put out a critical patch release for CVE-2026-110264. It's rated CVSS 10.0, the maximum, and it can let someone run code on your server without logging in. The Docker images landed around 2 am on 22 October, Australian eastern time.

The kicker: if you dutifully patched on 12 October for the last critical regex bug, you're vulnerable again. More on that below.

What it is, in plain words

GitLab's advisory is deliberately vague. It describes an integer overflow when compiling "a specially crafted regular expression" that could, "under certain conditions", let an unauthenticated user run arbitrary code.

GitLab's own security team filled in a lot more detail in the detection rules it published alongside the fix. The short version:

  • GitLab renders Org-mode (.org) files with a Ruby gem called org-ruby.
  • That gem takes custom keywords from a #+TODO: line in the file and drops them, raw, into a regular expression.
  • Make that keyword absurdly long and you overflow a counter in Onigmo, Ruby's regex engine. That leads to a memory write it shouldn't make.
  • With enough heap grooming, that ends up as a shell command running as the git user.

The git user owns everything that matters: every repo, your gitlab-secrets.json, CI/CD variables, runner tokens. Game over, basically.

GitLab's detection doc says the attack "needs no authentication — only one public project that can hold the .org payload." Somebody still has to get that file into a public project first, so if your instance is locked down that bar is higher. But I wouldn't bet my server on it. The same doc also describes a way through the editor's preview feature, and in their sample log that's a logged-in user. So "nobody can sign up" doesn't make you safe either. This is my reading of GitLab's notes, not something they've spelled out as a precondition, so treat it as unconfirmed.

Are you affected?

Almost certainly, if you self-host. According to GitLab, every CE and EE version from 7.0 (2014) up to these fixed releases is affected:

You're on Upgrade to
19.5.x 19.5.1
19.4.x 19.4.3
19.3.x 19.3.6
19.2.x 19.2.9
19.1.x 19.1.9
19.0.x 19.0.10
anything from 7.0 to 18.11 18.11.13

GitLab normally only patches the current release and the two before it, so the 19.2, 19.1, 19.0 and 18.11 fixes are backports. That tells you how seriously they're taking it. All install types are in scope (Linux package, Docker, Helm, source).

GitLab.com is already patched. GitLab Dedicated tenants on 19.3.5-internal0 / 19.4.2-internal0 or later don't need to do anything.

"But I patched on 12 October"

On 12 October GitLab fixed a different 10.0 regex bug, CVE-2026-97229, in the CI/CD config path, with 19.4.2, 19.3.5 and 19.2.8. Those versions are below the new fixed ones, so you're exposed to this one. Same researcher (joaxcar, via HackerOne), same regex engine, different route in.

What to do right now

1. Check your version. On a Linux package (Omnibus) install or inside the Docker container:

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
# or
sudo gitlab-rake gitlab:env:info

2. Take a backup. The package upgrade does an automatic database backup, but GitLab's own docs still tell you to keep a full one of your own. Also copy /etc/gitlab/gitlab-secrets.json and gitlab.rb somewhere safe.

3. Upgrade to the fixed patch for your minor version. Debian/Ubuntu example for CE on 19.4 (swap ce for ee and pick your version from the table):

sudo apt update && sudo apt install gitlab-ce=19.4.3-ce.0

RHEL/Alma/Rocky:

sudo dnf install gitlab-ce-19.4.3-ce.0.el9

Docker: bump your image tag to the fixed version (for example gitlab/gitlab-ce:19.5.1-ce.0), then pull and recreate the container. Don't just restart it.

Heads-up on downtime: 19.4.3 and 19.3.6 include database migrations, and on a single-node box GitLab says you'll get downtime while they run. For a homelab that's a cuppa's worth of outage. For a small team, give people a heads-up and just do it. Don't wait for the weekend.

If you're way behind (older than 18.11), you can't jump straight to 18.11.13. GitLab has required upgrade stops (for 18.x those are 18.2, 18.5, 18.8 and 18.11), and you need to let background migrations finish at each one. That's a longer job, so in the meantime seriously consider pulling the instance off the public internet. GitLab's detection doc itself suggests reducing public visibility until you're patched. Put it behind a VPN or Tailscale, or at least make public projects private.

If you run from source with your own Ruby build, the fix includes a patch to the bundled Ruby regex engine, not just GitLab's Rails code. One operator write-up points out that updating the app code alone may not get you the runtime fix. The packaged installs get it automatically.

Has anyone poked at your server?

GitLab published two detections: "Org mode render error burst" and "Onigmo native worker crash". You don't need a SIEM to use the idea. On an Omnibus install, this counts .org render timeouts per client, adapted from GitLab's doc:

grep '"exception.class":"Timeout::Error"' /var/log/gitlab/gitlab-rails/exceptions_json.log* \
  | grep '"extra.class_name":"OtherMarkup"' | grep -E '"extra.file_name":"[^"]*\.org"' \
  | grep -o '"meta.client_id":"[^"]*"' | sort | uniq -c | sort -rn

A handful of timeouts from one IP is a red flag. GitLab describes the attack as noisy and a "grind". Also look for [BUG] crash dumps mentioning org-ruby or Onigmo in /var/log/gitlab/puma/puma_stderr.log, and for .org files in public projects with ridiculously long #+TODO: lines.

One important catch from GitLab's own notes: a successful exploit can be quiet and might not crash anything, so clean logs don't prove you're fine. If you find anything dodgy, treat the box as compromised. That means rotating the secrets in gitlab-secrets.json, CI/CD variables, runner tokens and access tokens.

Where things stand

As of 9 am AEDT on 22 October:

  • Exploited in the wild? No reports that I could find. The Hacker News reports GitLab has seen no sign of it.
  • CISA KEV? Not listed. I checked the catalog (version 2026.10.21).
  • Public exploit? None I could find for this CVE. But Rapid7 published a working exploit write-up for the 12 October sibling within four days.
  • CVE record? Not live on CVE.org or NVD yet when I checked.

The bigger picture

That's four code-execution bugs in GitLab's regex handling from one researcher in about a month: two fixed on 23 September, one on 12 October, and now this. Once someone finds a soft spot in a native library buried deep in a big app, they keep pulling the thread, and every bit of user-controlled text that reaches that library becomes a way in. Today it's Org-mode files, a feature most GitLab users have never even used.

My take for self-hosters is simple. A GitLab instance is basically the keys to everything you build, so treat it like that. Subscribe to GitLab's security releases, patch within a day or two of a critical, and don't expose it to the whole internet unless you genuinely need to. If you can't commit to that, honestly, GitLab.com or a smaller forge might suit you better.

DampSnag