GitLab Patches Maximum-Severity Flaw Affecting Every Self-Managed Release Since 2014

GitLab shipped fixes on Oct. 21 for a flaw that could let an attacker run code on a self-managed server without logging in. The bug, tracked as CVE-2026-110264, is rated 10.0 on the CVSS scale. That is the maximum.

It reaches every self-managed version of the software back to 7.0, released in 2014.

What GitLab says is wrong

GitLab says that under certain conditions, an unauthenticated user could run arbitrary code on the server because of an integer overflow while compiling a specially crafted regular expression. The company has not said what those conditions are.

The CVSS assessment describes a network-based attack with low complexity, no account privileges and no user interaction. Impact on data privacy, data integrity and service availability is rated high.

The weak spot is Onigmo, the regular-expression engine built into Ruby. GitLab ships Onigmo inside its own packages and patches it in its own builds, so the flaw sits in every release that carries it.

GitLab credited a researcher using the handle joaxcar, who reported the issue through the company's HackerOne bug bounty program.

Which versions to install

Only self-managed installations of Community Edition and Enterprise Edition need to act. GitLab.com already runs the fixed version. GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later already have the fix.

The fixed self-managed versions are:

• 19.5.1
• 19.4.3
• 19.3.6
• 19.2.9
• 19.1.9
• 19.0.10
• 18.11.13

Anyone on 7.0 through 18.11 needs 18.11.13 at minimum. Earlier releases within each listed branch stay vulnerable.

Four of those versions are older than GitLab normally patches. Its policy covers the current release and the two before it, which as of today, Oct. 22, are 19.5, 19.4 and 19.3. GitLab backported the fix to 18.11, 19.0, 19.1 and 19.2 anyway, a step it reserves for severe issues.

Patching last week does not cover this

This is a separate bug from the one GitLab fixed on Oct. 12. That flaw, CVE-2026-97229, was also an unauthenticated 10.0 overflow in the regex compiler. It was fixed in 19.2.8, 19.3.5 and 19.4.2, and the update reached only 19.2 and later.

So an administrator on 19.0 or 18.11 who updated on Oct. 12 never got a fix for that bug. One on 19.2 or later who did update is now one patch behind the new fixed versions, and back in range for this flaw.

The Oct. 12 patch is the second in a run. On Sept. 23, GitLab fixed CVE-2026-93577 and CVE-2026-89078, both rated 9.9 but requiring a logged-in account. According to GitLab's disclosures, that makes four code-execution flaws in the regex engine credited to the same researcher in about a month. This is the first to reach versions before 19.2.

Exploitation status

GitLab reports no sign the flaw has been used in attacks and has published no public exploit. CVE-2026-110264 is not in the U.S. CISA catalog of known exploited vulnerabilities as of Oct. 22.

The 12-year reach describes how long the vulnerable code has shipped. It is not evidence that anyone has been exploiting it for 12 years.

GitLab did publish two detection rules for self-managed administrators, named "Onigmo native worker crash" and "Org mode render error burst." They are written in the Sigma format against GitLab's own application logs and are part of the company's open-source TLDR framework. GitLab has said nothing indicating the rules were prompted by observed attacks.

The unanswered question: who can reach the bug

Because GitLab has not disclosed the preconditions, administrators cannot rule themselves out by checking a configuration. The advisory offers no interim workaround. The fix is the only certain protection.

A separate technical write-up by ByteIota describes a possible path. It says GitLab renders Org-mode files through the org-ruby gem, which passes the contents of a `#+TODO:` keyword into a regular expression. If the keyword carries more than 32,767 repeats, it says, a signed 16-bit counter wraps negative and produces an out-of-bounds write. ByteIota says a public project is enough to trigger the rendering, which would make open instances easy to reach.

GitLab's own advisory does not confirm that chain or that any particular feature is required. Administrators should not assume a restriction GitLab has not stated.

What administrators should do

Self-managed operators should move to the matching fixed version for their branch. That means Omnibus packages, Docker images and source installs alike. GitLab's stated rule is that when an advisory does not name a deployment type, all types are affected.

Whether GitLab publishes the exploitation conditions, and whether CISA adds the CVE to its known-exploited list, will show how much time unpatched instances have. Neither had happened as of today.