On 21 October 2026 GitLab published fixes across seven release branches for CVE-2026-110264, a CVSS 10.0 defect that lets an unauthenticated attacker execute arbitrary code on a self-managed GitLab server. The flaw is an integer overflow in the Onigmo regular-expression compiler that GitLab bundles and maintains itself. It affects every self-managed version from 7.0 onward, which puts twelve years of deployed instances in scope.
The more important detail is administrative. Nine days earlier, on 12 October, GitLab fixed CVE-2026-97229, another 10.0 unauthenticated code execution in the same engine. That advisory covered 19.2, 19.3 and 19.4 only. The fixed versions for the new CVE are 19.2.9, 19.3.6 and 19.4.3, each one patch level above what the earlier advisory told administrators to install. An organisation that applied the 12 October update and confirmed completion is inside the affected range again, and nothing in the version string announces the regression.

What the vulnerability is

GitLab's advisory states that compiling a specially crafted regular expression could trigger an integer overflow and allow an unauthenticated user to run arbitrary code. NVD records the description in the same terms, with a CVSS v3.1 base score of 10.0.
The context that makes this reachable is the CI/CD configuration validation endpoint. A pipeline definition is user-supplied input that the server parses and compiles, and regular expressions inside it reach the Onigmo engine. Public analysis of the earlier CVE-2026-97229 describes the mechanism in more detail: the compiler computes the instruction length for a repeated expansion using 32-bit arithmetic, an oversized product wraps to a small or negative value, a size check that should reject the pattern accepts it instead, the buffer is allocated at the smaller size, and the resulting control-flow corruption leads to command execution.
GitLab has not published the precise preconditions for CVE-2026-110264. It states that no configuration workaround removes the risk, and that installing a fixed version is the only reliable defence.

Fixed versions and the support exception

The fixed releases are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. Four of the seven are outside GitLab's regular maintenance window, which covers the current and two previous monthly releases. The company backported beyond policy because of the severity.
GitLab.com already runs a fixed version. GitLab Dedicated tenants at 19.3.5-internal0 and 19.4.2-internal0 or later include the fix. Only self-managed installations need action.
There is an operational cost that belongs in the change plan rather than in the incident channel. The 19.4.3 and 19.3.6 upgrades include database migrations that run during the upgrade. Single-node installations will experience downtime. Multi-node deployments can use the zero-downtime procedure.

Why the version comparison must be exact

The failure mode here is not ignoring the patch. It is recording the patch as complete based on the maintenance window rather than the installed version string. An instance moved to 19.4.2 on 13 October satisfied the 12 October advisory and appears in any changelog-based audit as current. It is affected by CVE-2026-110264.
The practical rule is to collect gitlab-rake gitlab:env:info or read /opt/gitlab/version-manifest.txt from every self-managed instance, and to compare against the seven fixed versions rather than against a date.
Old instances deserve their own sweep. A version 7.0 installation from 2014 is inside the affected range, and so is any long-lived staging or lab deployment that stopped receiving updates. These systems are frequently outside external scanning, which means their absence from a vulnerability dashboard is not evidence that they are patched.

Detection rules and what they can and cannot show

GitLab published two detection rules in its TLDR framework, written in Sigma format and operating on GitLab application logs: "Onigmo native worker crash" and "Org mode render error burst".
Both rules address a real observable. Public reproduction of the earlier CVE-2026-97229 notes that the exploit request typically ends in an HTTP 502 because the worker crashes after executing the command. A worker crash during a request that should have returned a validation error is worth investigating.
The limit is that a 502 from a crashed worker is a common operational event. These rules identify candidates for review, not confirmed compromise, and their absence does not prove an instance was never exploited.

What to do beyond upgrading

The upgrade is the fix. The rest is scoping the window between 12 October and the patch, and before it.
Worth examining: CI/CD configuration changes from accounts that should not be writing them, unfamiliar branches in public projects, and the behaviour of the git account. The exploit runs as git, not as root, which sounds reassuring until you list what that account can read. On a typical GitLab server, the git user owns the repositories and reads pipeline variables, registry credentials and deployment keys.
Rotating CI secrets after patching is proportionate. Code execution as git gives an attacker everything configured for the pipeline, and replacing the binary does not invalidate credentials that were already copied.

References

  • GitLab security release, 21 October 2026, covering CVE-2026-110264

  • GitLab security release, 12 October 2026, covering CVE-2026-97229

  • NVD entries for CVE-2026-110264 and CVE-2026-97229

  • Rapid7, reproduction analysis of CVE-2026-97229

  • Tencent Cloud developer article, 22 October 2026, on the GitLab patch coverage gap