GitLab Patches Critical CVE-2026-110264 Affecting Versions Back to 7.0

GitLab has just fixed a critical flaw that has been present in the source code for 12 years, dating back to the release of version 7.0 in 2014. And if you updated your instance on October 12, you are exposed again to this new unauthenticated exploit. Here is what you need to know.

On October 21, 2026, GitLab released a critical patch for the Community (CE) and Enterprise (EE) editions of its platform. It fixes CVE-2026-110264, an integer overflow vulnerability in the regular expression compiler. "Under certain conditions, this issue could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to an integer overflow while compiling a specially crafted regular expression," the vendor explains.

In its security advisory, GitLab does not provide details about those exact conditions. What is certain is that if you self-host this solution, you need to act now to protect yourself. On GitLab.com, the platform is already running a fixed version, as are GitLab Dedicated instances on version 19.3.5-internal0 and 19.4.2-internal0 or later.

But be careful: do not assume you are already protected. On October 12, GitLab had already released security patches for CVE-2026-97229, another critical flaw exploitable without authentication through a malicious regex in a CI/CD configuration. The versions released at that time (19.2.8, 19.3.5 and 19.4.2) are vulnerable to the new flaw described in this article: CVE-2026-110264. In other words, those who rushed to patch will need to go back through maintenance again.

Why does the flaw go all the way back to GitLab 7.0?

The component involved is not code that is strictly native to GitLab. One of the detection rules published by the vendor refers to Onigmo, the regular expression engine built into Ruby. GitLab ships its own Ruby in its Omnibus packages and CNG images, and the fix takes the form of a patch applied to Ruby's regular expressions in 3.3, 3.4 and 4.0. That explains the broad range of affected versions.

Because this vulnerability is critical, GitLab made the effort to backport the fix to older maintained versions: 18.11.13, 19.0.10, 19.1.9 and 19.2.9. This is not standard practice, as GitLab currently maintains versions 19.5, 19.4 and 19.3.

I also want to highlight the work of researcher joaxcar, who has now uncovered a fourth code execution flaw in this regex engine in less than a month:

• CVE-2026-89078 and CVE-2026-93577 : fixed on September 23, CVSS score of 9.9, but an authenticated account was required.
• CVE-2026-97229 : fixed on October 12, CVSS score of 10, no authentication required, limited to versions 19.2 and later.
• CVE-2026-110264 : fixed on October 21, CVSS score of 10, no authentication required, and this time all the way back to version 7.0.

Which version should you install to stay protected?

The new versions released by GitLab fix a total of 12 vulnerabilities, including this critical flaw. There are also two high-severity issues (CVE-2026-15723 (CVSS 8.2) and CVE-2026-112212 (CVSS 7.5)).

Here is the version to install depending on the branch you are using:

• 19.5 : 19.5.1
• 19.4 : 19.4.3
• 19.3 : 19.3.6
• 19.2 : 19.2.9
• 19.1 : 19.1.9
• 19.0 : 19.0.10
• From 7.0 to 18.11 : 18.11.13

Plan for a service interruption, because versions 19.4.3 and 19.3.6 include database migrations that run during the update: on a single-node instance, GitLab will not restart until those migrations are complete.

As of today, GitLab's advisory does not mention any active exploitation, and the flaw is not listed in the CISA KEV catalog.

Florian Burnel Co-founder of IT-Connect

Systems and network engineer, co-founder of IT-Connect and Microsoft MVP "Cloud and Datacenter Management". I'd like to share my experience and discoveries through my articles. I'm a generalist with a particular interest in Microsoft solutions and scripting. Enjoy your reading.

See Full Bio