GitLab patches unauthenticated CVSS 10.0 regex flaw reaching back to 2014

GitLab released fixes on Oct. 21, 2026 for CVE-2026-110264, an unauthenticated remote code execution flaw in self-managed servers that reaches back to version 7.0 from 2014, The Hacker News reported. The vulnerability carries the maximum CVSS score of 10.0, the highest possible rating on the common vulnerability scoring system. GitLab says the flaw lets an unauthenticated user run arbitrary code due to an integer overflow during compilation of a specially crafted regular expression. An integer overflow occurs when a calculation produces a value too large for the variable that should hold it, and in this case the overflow happens inside the regex compiler that GitLab bundles with its software.

The breadth of the impact traces to a technical detail: GitLab ships Ruby’s built-in Onigmo regular-expression compiler inside its own packages, so the weakness exists in every release since 7.0 from 2014. Because GitLab bundles and maintains the regex engine itself, the defect propagates to all historical releases that include it. GitLab has not said what preconditions an attacker needs to reach the compiler, so administrators cannot rule themselves out by configuration. GitLab has not disclosed the conditions required to exploit the flaw, and it reports no sign that attackers have used the flaw in attacks.

The U.S. CISA catalog of known exploited vulnerabilities did not list CVE-2026-110264 as of Oct. 22.

The Oct. 21 patch arrived nine days after an Oct. 12 update that covered only versions 19.2 and later. On Oct. 12, GitLab fixed CVE-2026-97229, an unauthenticated overflow in the regex compiler rated at 10.0, in versions 19.2.8, 19.3.5, and 19.4.2. Earlier, on Sept. 23, GitLab fixed CVE-2026-93577 and CVE-2026-89078, both rated 9.9 and requiring a logged-in account. Researcher joaxcar has reported four code-execution flaws in GitLab’s regular-expression engine within one month.

CVE-2026-110264 is the first of those flaws to reach versions before 19.2, while the three earlier regular-expression flaws reached only version 19.2. This one extends the exposed surface much further back. GitLab patched the flaw in seven versions at once, four of which are older than GitLab normally patches. The vendor issued fixes across multiple release branches simultaneously rather than a single update.

GitLab’s normal policy covers the current release and the previous two monthly releases, 19.5, 19.4, and 19.3 as of Oct. 22, and the standard support window covers three monthly release branches, leaving older branches uncovered unless backported. Beyond those standard releases, GitLab backported the fix to 18.11.13, 19.0.10, 19.1.9, and 19.2.9, and the company reserves backporting for severe issues.

GitLab’s advisory offers no interim workaround, leaving the patch as the only certain protection. To help self-managed administrators hunt for exploitation attempts in their own logs, GitLab published detection rules named Onigmo native worker crash and Org mode render error burst in its open-source TLDR framework. GitLab’s detection framework expresses the rules in Sigma format for analysis of GitLab application logs.

Only self-managed installations require action because GitLab.com already runs the fixed version. GitLab Dedicated tenants on internal releases 19.3.5-internal0 and 19.4.2-internal0 or later already include the fix. Organizations that rely on GitLab’s hosted service or dedicated instance do not need to patch, but every self-managed server, regardless of its age, does.

Among the other fixes, CVE-2026-15723, rated high at 8.2, could allow a logged-in user to take over another account when an administrator has enabled both SAML and LDAP auto-linking. CVE-2026-112212, scored at 7.5, is a cache-poisoning flaw affecting the OAuth and OpenID Connect endpoints; in shared-cache deployments it can redirect sign-in traffic to a server under an attacker’s control.

Releases 19.4.3 and 19.3.6 include database changes that run during upgrade, causing downtime on single-node servers. Database migrations during the upgrade require single-node instances to go offline temporarily. Multi-node setups can apply the patch without downtime using GitLab’s zero-downtime procedure, which allows larger installations to avoid service interruption by following the vendor’s zero-downtime upgrade process.