What CVE-2026-110264 is
GitLab uses Ruby’s built-in regular expression engine, Onigmo. When that engine compiles a specially crafted regular expression, an integer overflow occurs, and GitLab says this can be turned into arbitrary code execution on the server, running as the git user, with no account required. The overflow is in the engine itself, which is why the flaw reaches all the way back to GitLab 7.0.
The reachable path, per GitLab’s own detection rule: GitLab renders Org-mode files (a plain-text document format) with the org-ruby gem, which builds a regex from the keyword on a #+TODO: line of a .org file without escaping it. A keyword repeated more than 32,767 times overflows a counter in the regex engine. The attack needs no login, only one public project holding the crafted .org file for GitLab to render. A successful attempt can be quiet and does not reliably crash the server.
GitLab rates it CVSS 10.0. Treat that as authoritative.
Who is affected
Only self-managed GitLab needs action, Community Edition and Enterprise Edition, on every install method (Linux package, Docker, Helm, source).
- GitLab.com already runs the fixed version. Nothing to do.
- GitLab Dedicated tenants on the fixed internal builds already have it. Nothing to do.
- Self-managed, any version from 7.0 onward: affected. Assume in scope until you confirm the version.
The 12 October trap
This is the part that catches teams who thought they were already covered. On 12 October, GitLab fixed a different regex flaw (CVE-2026-97229) in 19.4.2, 19.3.5 and 19.2.8. CVE-2026-110264 is a separate, wider-reaching bug. A server upgraded to those 12 October releases is still exposed and needs the next patch up. Both flaws were reported by the same researcher, and this is the fourth regex-engine issue from them in a month.
The fix: patch to your line’s version
Released 21 October 2026 for both CE and EE:
| If you run | Upgrade to | Notes |
|---|---|---|
| 19.5 | 19.5.1 | All 12 fixes |
| 19.4 | 19.4.3 | All 12 fixes, includes DB migrations |
| 19.3 | 19.3.6 | All 12 fixes, includes DB migrations |
| 19.2 | 19.2.9 | Critical fix only |
| 19.1 | 19.1.9 | Critical fix only |
| 19.0 | 19.0.10 | Critical fix only |
| 18.11 | 18.11.13 | Critical fix only |
| 18.10 and older | No fixed release | Upgrade to a supported line |
Stay on the minor version you run (for example 19.4.x goes to 19.4.3); a patch-level upgrade needs no extra upgrade stops. Only 19.4.3 and 19.3.6 include database migrations, so a single-node server stays down until they finish. Multi-node installs can follow GitLab’s zero-downtime procedure.
For the exact per-install-type commands, the version check, and how to run GitLab’s two detection rules over your logs, see our GitLab CVE-2026-110264 patching runbook.
If you are on GitLab 18.10 or older: this is a modernisation decision
There is no fixed release below the 18.11 line. If a self-managed instance is on 18.10 or earlier, patching is not an option, you have to upgrade to a supported version, and GitLab upgrades across several minor versions require staged “upgrade stops” (you cannot jump straight to the latest). In practice, an instance left that far behind is usually behind on its OS, its runners, and its backup story too.
The honest framing: you were always going to have to bring that GitLab current. CVE-2026-110264 just set the deadline, and the cost of waiting is now an unauthenticated, maximum-severity RCE on the server that holds your source code and quite possibly your deployment secrets.
What to do this week
- Inventory every self-managed GitLab instance. Include Geo secondaries, staging, DR, and test boxes. A forgotten instance is still a way in.
- Check the version each one actually serves (not just the CLI; the runbook has the per-install commands).
- Patch supported lines immediately to the version in the table. If you patched on 12 October, go one patch higher.
- Triage anything on 18.10 or older: plan the upgrade path, or take it off the public internet until you can.
- Check for exploitation attempts using GitLab’s detection rules, and if you find signs of compromise, rotate CI/CD variables, runner tokens, deploy keys, and access tokens held on the server.
As of 22 October there were no reported attacks, the flaw was not in CISA’s KEV catalog, and no public proof of concept had surfaced. That is the window you are patching inside. The researcher’s previous flaw was reproduced by Rapid7 within a day of release, so do not count on it staying quiet.
Not sure which of your GitLab instances are exposed?
We help teams inventory self-managed GitLab, patch the supported lines safely (including the migration-bearing releases), and plan the upgrade path for anything stuck on an unsupported version. See our Security & Compliance work or book a call below.
Running self-managed GitLab?
Book a free 30-minute call. We'll help you confirm what's patched, handle the migration-bearing upgrades, and plan a path off any unsupported version.
