Securify

On October 21, GitLab disclosed CVE-2026-110264, a critical unauthenticated remote code execution vulnerability carrying the maximum CVSS score of 10.0. What makes this flaw particularly alarming is its reach: every self-managed GitLab Community Edition and Enterprise Edition installation dating back to version 7.0 — released in 2014 — is affected. That is twelve years of releases, encompassing virtually every self-hosted GitLab instance on the planet.

Administrators running self-managed GitLab should treat this as a drop-everything-and-patch situation. GitLab.com and GitLab Dedicated tenants are already running fixed versions, but the tens of thousands of organizations hosting their own instances face immediate risk.

What the Flaw Is

The vulnerability lives in Onigmo, the regular expression engine that Ruby ships and that GitLab bundles in its own builds. Specifically, an integer overflow occurs during the compilation of a specially crafted regular expression. When an attacker supplies a malicious regex through GitLab’s CI/CD configuration pipeline, the overflow can redirect the regex engine’s execution flow to a command-execution function — giving the attacker arbitrary code execution on the server.

The critical detail is that no authentication is required. GitLab’s advisory states the flaw “could allow an unauthenticated user to execute arbitrary code on the GitLab server under certain conditions.” Those conditions have not been publicly specified, which means administrators cannot determine through configuration alone whether their instance is safe. The only certain protection is patching.

A Pattern of Regex Engine Flaws

CVE-2026-110264 is not an isolated incident. It is the fourth regex-engine code execution flaw reported in GitLab within a single month, all attributed to a researcher known as joaxcar. The previous three include:

• CVE-2026-97229 (October 12) — CVSS 10.0, unauthenticated RCE via the CI/CD regex compiler, but limited to versions 19.2 and later. A public proof-of-concept published by researcher Jonah Burgess demonstrated a working exploit chain against GitLab CE 19.4.1.
• CVE-2026-93577 (September 23) — CVSS 9.9, integer overflow in the regex compiler requiring an authenticated account.
• CVE-2026-89078 (September 23) — CVSS 9.9, a double-free in the regex parser, also requiring authentication.

The pattern is striking: a single researcher has uncovered a family of related memory corruption bugs in the same regex engine component, each one escalating in severity. CVE-2026-110264 is the most dangerous yet because it combines the unauthenticated attack vector with the broadest version coverage — stretching all the way back to 2014.

Who Is Affected and How to Patch

The vulnerability affects all self-managed GitLab CE and EE installations from version 7.0 onward. GitLab has released patched versions across every supported branch. Administrators should upgrade to one of the following:

• 19.5.1 (for those on the 19.5 branch)
• 19.4.3 (for the 19.4 branch)
• 19.3.6 (for the 19.3 branch)
• 19.2.9 (for the 19.2 branch)
• 19.1.9 (for the 19.1 branch)
• 19.0.10 (for the 19.0 branch)
• 18.11.13 (for versions 7.0 through 18.11)

The decision to backport the fix all the way to 18.11.13 is significant — GitLab reserves this kind of deep backport for the most severe vulnerabilities. Organizations that applied the October 12 patches for CVE-2026-97229 and believed they were safe should note that those fixes only addressed versions 19.2 and later, meaning instances patched then are affected again by this broader flaw.

One important operational note: the 19.4.3 and 19.3.6 releases include database migrations that cause downtime on single-node servers. Organizations running multi-node architectures can use GitLab’s zero-downtime upgrade procedure, but solo-instance shops should plan a maintenance window.

No Workaround, No Exploitation — Yet

GitLab has not published any interim workaround or mitigation short of upgrading. The company has also not disclosed the specific preconditions that enable exploitation, which means security teams cannot perform a meaningful risk assessment beyond assuming they are vulnerable.

On the positive side, GitLab reports no evidence of exploitation in the wild as of October 22, and the flaw has not been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog. However, given that a proof-of-concept already exists for the closely related CVE-2026-97229, it would be unwise to assume exploitation is far off. GitLab has published two Sigma-format detection rules — “Onigmo native worker crash” and “Org mode render error burst” — through its TLDR framework, giving defenders at least some ability to detect exploitation attempts.

The Bigger Picture

This disclosure raises deeper questions about the security of regex engines in critical infrastructure software. Onigmo is not a niche library — it is the default regex engine in Ruby, which means any Ruby application that compiles user-supplied regular expressions could theoretically face similar risks. GitLab’s exposure is particularly acute because its CI/CD pipeline system processes configuration files that may originate from untrusted sources, such as forked repositories or external contributors.

The cadence of discoveries is also notable. Four critical-to-maximum-severity regex bugs in under 30 days suggests that joaxcar has found a fruitful attack surface, and the pattern may not be over. Organizations relying on self-managed GitLab should establish a rapid-response patching cadence for the foreseeable future and consider whether their CI/CD pipeline configurations are adequately locked down against untrusted input.

What to Do Right Now

Patch immediately. Verify which GitLab version you are running, identify the correct target version from the list above, and schedule the upgrade with urgency. If you are on a single-node deployment, plan for brief downtime during database migrations.

Review CI/CD configurations. Audit recent changes to pipeline configuration files, paying attention to new or modified regular expressions and any branches from untrusted contributors. If your instance allows public projects or accepts merge requests from external users, the attack surface is wider.

Deploy detection rules. Implement GitLab’s published Sigma rules for Onigmo worker crashes and Org-mode rendering error bursts. While these are not preventive, they can provide early warning of exploitation attempts.

Watch for follow-up advisories. Given the pace of regex engine disclosures, another patch cycle within weeks is plausible. Ensure your team is subscribed to GitLab’s security alert mailing list and monitoring the official advisory page.

GitLab plans to make the vulnerability’s technical details public 90 days after the patch release. Until then, the clock is ticking for every unpatched self-managed instance.