DEV Community

StarkMan
StarkMan

Posted on

GitLab's seven-branch backport: what CVE-2026-110264 does to upgrade sequencing

#gitlab #cve2026110264 #patchmanagement #onigmo

GitLab's seven-branch backport: what CVE-2026-110264 does to upgrade sequencing

GitLab's October 21 patch release created an unusual planning problem for the administrators who had already upgraded nine days earlier. The October 12 release covered only 19.2 and later. The new fix sits one patch above it. An instance updated on October 12 is in range again, and the flaw carries the highest score GitLab can assign.

The flaw and its score

CVE-2026-110264 is rated 10.0. GitLab's description is narrow: under certain conditions, an unauthenticated user could run arbitrary code on a self-managed server because of an integer overflow during the compilation of a specially crafted regular expression. GitLab has not published what those conditions are.
The company reports no sign of exploitation, and the CVE does not appear in CISA's known exploited vulnerabilities catalog. Only self-managed installations need to act. GitLab.com already runs the fixed version, and GitLab Dedicated tenants on internal releases 19.3.5-internal0 and 19.4.2-internal0 or later already have the fix.

Why the fix reaches back to 7.0

The affected component explains the version spread. The regular-expression compiler in question is Ruby's Onigmo engine, which GitLab ships inside its own packages and patches in its own builds. The weakness is present wherever that engine was shipped, which means every release since 7.0 in 2014. This is the fourth code-execution flaw in the same engine reported by the same researcher within a month, and the first to reach versions before 19.2.
Anyone reading the score in isolation should read the history first. The three earlier flaws, CVE-2026-97229, CVE-2026-93577 and CVE-2026-89078, stopped at version 19.2. Two of them required a logged-in account. This one does not, and GitLab has not described the preconditions that would let an administrator rule their configuration out.

The version map

GitLab fixed the flaw across seven branches at once. Four of those branches are older than its normal patch policy, which covers the current release and the previous two monthly releases.
| If you run | Upgrade to |
| --- | --- |
| 19.5 before 19.5.1 | 19.5.1 |
| 19.4 before 19.4.3 | 19.4.3 |
| 19.3 before 19.3.6 | 19.3.6 |
| 19.2 before 19.2.9 | 19.2.9 |
| 19.1 before 19.1.9 | 19.1.9 |
| 19.0 before 19.0.10 | 19.0.10 |
| 7.0 through 18.11 before 18.11.13 | 18.11.13 |
The backports to 18.11.13, 19.0.10, 19.1.9 and 19.2.9 are steps GitLab says it reserves for severe issues. Read the backports as a scheduling signal. An instance on an out-of-policy branch is not abandoned, but it sits on a temporary extension rather than a maintained train.

The two supporting flaws in the same release

The release fixes eleven security issues in total. Two of the others affect authentication and deserve separate attention because their preconditions are documented.
CVE-2026-15723, rated 8.2, could let a logged-in user take over another account when an administrator has enabled both SAML and LDAP auto-linking. The mitigation is configuration review as much as patching. If auto-linking is enabled and not needed, the combination deserves questioning on its own terms.
CVE-2026-112212, rated 7.5, is a cache-poisoning flaw in GitLab's OAuth and OpenID Connect endpoints. In setups that use a shared cache, an attacker could redirect certain sign-in flows to a server they control.

Downtime is part of the plan

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 while the migrations finish. GitLab states that multi-node installations can apply the patch without downtime using its zero-downtime procedure. If your change window assumes a package swap and a service restart, resize it.

Detection before and after the upgrade

GitLab published two detection rules for self-managed administrators, 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 the Sigma format against GitLab's own application logs.
Those rules are a starting point rather than proof of absence. Because GitLab has not described the preconditions for reaching the compiler, an administrator cannot exclude their instance by configuration. The advisory offers no interim workaround. The fix is the only certain protection, so deployment order becomes the real decision. Fix externally reachable instances first, then internal ones, and record which build each host reports after the upgrade rather than which package was downloaded.

What remains unknown

The source material does not describe the specific regular expression that triggers the overflow, does not enumerate the "certain conditions" GitLab refers to, and does not establish whether the earlier researcher reports share an exploitation technique. It also does not translate the Onigmo version history into a per-branch risk ranking. Those gaps are reasons to verify each host's reported version after patching.

References

Top comments (0)