A critical flaw in GitLab (CVSS 10.0) could allow unauthenticated RCE over 12 years of versions

GitLab released patches on October 21 for a flaw that allows an attacker to run code on a self-managed server without logging in, and this affects all versions of the software since 7.0, released in 2014.

The fix is ​​important even for administrators who applied the patch nine days earlier: the October 12 update only covered versions 19.2 and later, and the new patched versions sit one patch above it, so an updated instance then is within reach again.

The flaw, identified as CVE-2026-110264, is rated 10.0 on the CVSS scale, the maximum. GitLab says that, under certain conditions, it could allow an unauthenticated user to execute arbitrary code on the server due to an integer overflow when compiling a specially crafted regular expression.

GitLab did not specify what these conditions are. The company reports no signs that the flaw has been used in attacks, and it is not listed in the US CISA catalog of known exploited vulnerabilities as of October 22.

Only self-managed installations should act. GitLab.com is already running the patched version, and GitLab Dedicated tenants on internal versions 19.3.5-internal0 and 19.4.2-internal0 or later already have the patch.

GitLab fixed the flaw in seven versions at once.

The table below associates each release branch with the release that fixes it.

Four of these releases are older than GitLab’s usual patches. The company’s policy covers the current release and the previous two monthly releases, which are, as of today, 19.5, 19.4, and 19.3.

GitLab said it backported this patch 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 serious issues.

The reason the flaw goes back so far is the part of GitLab that failed. The regular expression compiler is Ruby’s built-in engine, called Onigmo, which GitLab provides in its own packages and patches in its own releases. A weakness of this engine is present wherever GitLab has delivered it, that is to say in every release since version 7.0.

GitLab also released two detection rules to help self-managed administrators scan for exploitation attempts, named “Onigmo Native Worker Crash” and “Org Mode Render Error Burst.” They are part of the company’s open source TLDR framework, which writes each detection in Sigma format to GitLab’s own application logs.

GitLab has not specified the prerequisites an attacker needs to reach the compiler, so administrators cannot yet opt ​​out through configuration; the patch is the only certain protection, and GitLab’s advisory offers no temporary workaround.

This is the fourth code execution flaw in GitLab’s regular expression engine that the same researcher, who goes by the handle joaxcar, has reported in a month, and the first to reach versions prior to 19.2.

On October 12, GitLab fixed CVE-2026-97229, also an unauthenticated 10.0 overflow in the regex compiler, in versions 19.2.8, 19.3.5, and 19.4.2. On September 23, it fixed two more, CVE-2026-93577 and CVE-2026-89078, both rated 9.9 but requiring a logged in account. The three previous flaws stopped at version 19.2; this one doesn’t.

The October 21 release fixes 11 security issues in total, one critical and the rest high, medium or low.

Two of the others concern authentication. CVE-2026-15723, rated 8.2, could allow a logged in user to take over another account, but only when an administrator has enabled SAML and LDAP auto-linking.

A cache poisoning vulnerability in GitLab’s OAuth and OpenID Connect endpoints, CVE-2026-112212, rated 7.5, could allow an attacker to redirect certain connection flows to a server they control in configurations using a shared cache.

Upgrading comes with a cost that is worth planning for. Versions 19.4.3 and 19.3.6 include database changes that run during the upgrade and on a single-node server, resulting in downtime until completion. GitLab says multi-node setups can apply the patch without downtime using its zero-downtime procedure.