GitLab has released a security update for a critical vulnerability that could let attackers run code on self-managed servers without logging in. The flaw carries a CVSS score of 10.0, the highest possible rating, and affects GitLab versions dating back to 7.0, released in 2014.
Tracked as CVE-2026-110264, the vulnerability comes from an integer overflow in the regular expression compiler when it processes a specially crafted expression. An attacker could exploit it to run malicious code on a vulnerable server, potentially exposing source code, credentials, and other sensitive data.
GitLab released fixes on October 21 across seven release branches. The company has not confirmed any attacks exploiting the flaw, but it has not shared the exact conditions needed to trigger it either. There is also no known workaround, making an upgrade the only confirmed fix.
The timing makes this issue more serious. On October 12, GitLab fixed another critical vulnerability in the same component, CVE-2026-97229. However, that update covered versions 19.2 and later. The latest flaw also affects older releases, including versions dating back to 2014. This means administrators who installed the previous patch may still need to update their servers.
GitLab recommends upgrading to these fixed versions:
| Current release | Fixed version |
|---|---|
| 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 |
| 7.0 to 18.11 | 18.11.13 |
GitLab has also released fixes for older versions that are normally outside its maintenance policy. This shows how seriously the company is treating the issue.
The flaw affects Onigmo, the regular expression engine built into Ruby. GitLab includes this engine in its software packages, which explains why the vulnerability reaches so many versions.
This is also the fourth code execution flaw involving the same engine reported by the researcher known as joaxcar in about a month. Unlike the earlier issues, this one affects releases older than version 19.2.
GitLab.com users are already protected because the service runs a fixed version. GitLab Dedicated customers on specified fixed internal releases are also covered. Administrators running their own GitLab servers must check their versions and apply the relevant update.
GitLab has published two detection rules to help administrators look for possible exploitation attempts in application logs. However, these rules are not a replacement for installing the patch.
My concern is the combination of the flaw’s severity, its long history, and the lack of clear information about the conditions required to exploit it. Although GitLab has reported no known attacks, that does not mean attackers will ignore it. The repeated discovery of flaws in the same component also raises questions about whether further weaknesses could be found.
Administrators should not assume that installing the October 12 update is enough. They should verify their current version and apply the latest fix. Some upgrades also involve database changes that can cause downtime on single-node servers, so organisations should plan the update carefully rather than delay it indefinitely.
