CVE-2026-110264: Unauthenticated GitLab RCE (CVSS 10.0) Reaches Every Release Since 7.0

TL;DR

• what: GitLab fixed CVE-2026-110264 on October 21, an integer overflow in its bundled Onigmo regular-expression engine that allows unauthenticated remote code execution.
• impact: Every self-managed GitLab release since 7.0 (2014) is affected, including instances patched on October 12, and a compromised server exposes source code, CI/CD secrets and deploy credentials.
• fix: GitLab released fixed versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, and lists no interim workaround.
• who: Organizations running self-managed GitLab; GitLab.com and GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later are already fixed.

On October 21, GitLab shipped fixes for CVE-2026-110264, a CVSS 10.0 flaw that lets an attacker run arbitrary code on a self-managed GitLab server without logging in. The bug affects every release since GitLab 7.0, which came out in 2014. That is about 12 years of installs, and it includes servers patched only nine days ago.

The October 12 update fixed a related regex flaw, but only in 19.2 and later. Each new fixed version sits one patch above the October 12 build for its branch, so an instance that updated on October 12 is vulnerable again.

What the Flaw Is

GitLab describes the bug as an integer overflow that happens when a specially crafted regular expression is compiled. Under certain conditions, it lets an unauthenticated user execute arbitrary code on the server. GitLab has not said what those conditions are.

The vulnerable component is Onigmo, the regular-expression engine built into Ruby. GitLab ships Onigmo inside its own packages and applies its own patches to it. A defect in that engine is present in every release that bundles it. That explains why the affected range goes all the way back to 7.0 instead of stopping at a recent feature change.

⚠️ No configuration rules you out — GitLab has not published what an attacker needs in order to reach the vulnerable compiler path, and its advisory offers no interim workaround. Until those details are public, administrators cannot clear an instance through configuration. The patched release is the only confirmed protection.

Fixed Versions

GitLab patched seven release branches at once:

• 19.5 before 19.5.1: fixed in 19.5.1
• 19.4 before 19.4.3: fixed in 19.4.3
• 19.3 before 19.3.6: fixed in 19.3.6
• 19.2 before 19.2.9: fixed in 19.2.9
• 19.1 before 19.1.9: fixed in 19.1.9
• 19.0 before 19.0.10: fixed in 19.0.10
• 7.0 through 18.11, before 18.11.13: fixed in 18.11.13

Four of those versions fall outside GitLab's normal support window. Its policy covers the current release and the previous two monthly releases, which today are 19.5, 19.4 and 19.3. GitLab backported the fix to 18.11.13, 19.0.10, 19.1.9 and 19.2.9 in addition to its standard releases, a step it reserves for severe issues. Any instance on a version from 7.0 through 18.11 is fixed in 18.11.13.

Only self-managed installations are exposed. GitLab.com already runs the fixed code. GitLab Dedicated tenants on internal releases 19.3.5-internal0 and 19.4.2-internal0 or later already have the fix.

Exploitation Status and Detection

GitLab reports no evidence that the flaw has been used in attacks. As of October 22, CVE-2026-110264 is not in the CISA Known Exploited Vulnerabilities catalog. That window may not last. The engine is open source, so the fix shows exactly where the overflow is, and this class of bug has now had four public patches in four weeks.

GitLab also published two detection rules for exploitation attempts: "Onigmo native worker crash" and "Org mode render error burst." Both are part of GitLab's open-source TLDR framework, which writes each detection in Sigma format against GitLab's own application logs. The name of the second rule suggests that rendering Org mode files is one route to the vulnerable compiler. GitLab has not confirmed that.

A Pattern, Not a One-Off

This is the fourth code-execution flaw in GitLab's regular-expression engine reported in about a month by the same researcher, who uses the handle joaxcar. It is the first of the four to reach versions before 19.2.

• September 23: CVE-2026-93577 and CVE-2026-89078, both CVSS 9.9, both requiring a logged-in account.
• October 12: CVE-2026-97229, CVSS 10.0, unauthenticated overflow in the regex compiler, fixed in 19.2.8, 19.3.5 and 19.4.2.
• October 21: CVE-2026-110264, CVSS 10.0, unauthenticated, affecting every version back to 7.0.

When researchers focus on a single native component, the bugs tend to come in clusters. Four overflows in one bundled engine in four weeks points to more GitLab releases outside the normal schedule in the coming months. Change windows planned around GitLab's monthly cadence should expect that.

The Rest of the October 21 Release

The release fixes 11 security issues in total: one critical, with the rest rated high, medium or low. Two of the others concern authentication:

• CVE-2026-15723, CVSS 8.2: a logged-in user could take over another account, but only when an administrator has turned on both SAML and LDAP auto-linking.
• CVE-2026-112212, CVSS 7.5: cache poisoning in the OAuth and OpenID Connect endpoints could let an attacker redirect certain sign-in flows to a server they control, in deployments that use a shared cache.

Upgrade Cost

The 19.4.3 and 19.3.6 releases include database changes that run during the upgrade. On a single-node server, that means downtime until they finish. GitLab says multi-node deployments can apply the patch without downtime by following its zero-downtime procedure. Teams on single-node instances will need to schedule a maintenance window, and that pressure grows with the CVSS score.

Why a GitLab server is a high-value target — A self-managed GitLab host usually holds source code, CI/CD variables, deploy keys, runner registration tokens and integration credentials for cloud and production systems. Unauthenticated code execution on that host is a direct path into every pipeline and environment it deploys to.

RedEye Assessment

CVE-2026-110264 is the most serious GitLab issue of the year so far. It needs no login, the vendor rates it at the maximum score, it reaches back 12 years of releases, and no workaround exists. It also cancels the protection that administrators thought they had after October 12. Every self-managed GitLab instance, including forgotten legacy servers from before 18.11, should be treated as exposed until it runs one of the seven fixed versions GitLab has named.

Originally published on RedEye Threat Intelligence.