CVE-2026-110264: GitLab Critical RCE Reaches Back to Version 7.0

GitLab's patch release of October 21, 2026 fixes 12 vulnerabilities, and one of them is as bad as the CVSS scale allows. CVE-2026-110264 is an integer overflow in GitLab's regular expression compiler that, under certain conditions, could let an unauthenticated attacker run arbitrary code on the GitLab server. GitLab scores it 10.0, and it affects GitLab CE and EE from version 7.0 up to the fixed releases, which is where the headlines about a 12-year-old bug come from.

GitLab.com and GitLab Dedicated are already patched, so the work falls on self-managed installations. GitLab reports no confirmed attacks and no public exploit, and its advisory offers no workaround. This post covers what is known about the flaw, which versions to move to, and how to read its entry on VulnTracker.

What GitLab has said about the flaw

GitLab's advisory is short. It calls the issue an integer overflow in the Regular Expression Compiler, triggered when GitLab compiles a specially crafted regular expression, and says an unauthenticated user could use it to execute arbitrary code on the server. In general terms, an integer overflow happens when a calculation produces a number too large for the space reserved for it, and the result wraps around to a small one. In a compiler that sizes memory from such a number, that can lead to memory corruption, which is how a bug like this becomes code execution.

The CVSS 3.1 vector is network attack, low complexity, no privileges, no user interaction, with a changed scope and high impact on confidentiality, integrity and availability. Changed scope means the damage is not limited to the vulnerable component.

What the advisory leaves out is just as important. It does not say which GitLab feature accepts the attacker's expression, what the "certain conditions" are, or whether a default installation is exposed. Clues point to Ruby's regular expression engine, Onigmo, which GitLab bundles: the release includes patches titled as a Ruby regexp repeat ID overflow fix for Ruby 3.3, 3.4 and 4.0, and one of GitLab's detection rules is named Onigmo native worker crash. That is an inference from those names, not a statement in the advisory, though at least one news report states it as fact.

GitLab credits a researcher using the handle joaxcar, who reported the flaw through its HackerOne bug bounty program. The advisory includes two detection rules for self-managed installations, Onigmo native worker crash and Org mode render error burst, aimed at spotting exploitation attempts in application logs. Cyber Security News notes that these rules are not evidence that attacks happened. GitLab has not published a proof of concept, and none of the pages read for this post reports one.

Who is affected

GitLab lists every version of GitLab CE and EE from 7.0 up to the fixed release of its branch. Each deployment type is affected unless GitLab says otherwise, and the advisory says GitLab.com and GitLab Dedicated have already been patched.

Branch	Affected	Fixed in
7.0 to 18.11	All versions before 18.11.13	18.11.13
19.0	Before 19.0.10	19.0.10
19.1	Before 19.1.9	19.1.9
19.2	Before 19.2.9	19.2.9
19.3	Before 19.3.6	19.3.6
19.4	Before 19.4.3	19.4.3
19.5	Before 19.5.1	19.5.1

The 19.0, 19.1 and 19.2 releases are backports that GitLab issued in addition to its standard patch releases. The advisory lists no separate fix for branches older than 18.11, so anyone on an older version has to upgrade to 18.11.13 or later.

The upgrade is not a drop-in file swap. The patch includes database migrations, so single-node instances will see downtime while they run, and multi-node instances can use zero-downtime upgrades. GitLab lists regular migrations in 19.4.3 and 19.3.6, and a post-deploy migration in 19.4.3.

One point to check by version, not by date. GitLab published an earlier update on October 12. Reporting about it disagrees: Cyber Security News says it dealt with a different CVE and does not address this one, while another outlet suggests an instance updated then could be back in range. GitLab's October 21 advisory does not mention that earlier update, so compare your running version with the table above and do not rely on when you last patched.

A perfect score with no map

The age of the bug draws the attention, but the more useful fact for defenders is how little is public. The flaw is rated 10.0, requires no login, and needs no click from anyone, yet GitLab has said nothing about the feature that reaches the compiler or the conditions an attacker needs. A team cannot tell from the advisory which of its instances are exposed, so the safe assumption is that all self-managed instances on the listed versions are.

The version range also carries a timeline detail. GitLab's advisory says affected versions start at 7.0, which was released in 2014, and both Cyber Security News and THN use that to describe a 12-year-old bug. Cyber Security News adds that this does not mean attackers have used the flaw for twelve years, and the advisory does not say when the flaw was introduced. What matters now is the gap that starts with the patch: a fix is public, details are not, and the code change itself will be available to anyone who compares versions.

Exploitation is the other open question. GitLab reports no confirmed attacks and no public exploit, and VulnTracker's SSVC reads No known exploit, Automatable, Total impact. That pairing is a signal to prepare, not to relax: when a flaw is automatable and gives total control, the day an exploit appears is the day scanning starts at scale. The HackerOne report behind the fix is listed on VulnTracker with tags for technical description and exploit, but the report could not be opened for this post, so its contents are unverified.

There is also a practical reason to move quickly regardless of the headline CVE. The same release carries 11 other fixes, including two rated High: an improper authentication flaw in OmniAuth-to-LDAP account linking (CVE-2026-15723, 8.2) and OAuth or OIDC discovery cache poisoning (CVE-2026-112212, 7.5). One upgrade closes all of them.

Reading it on VulnTracker

The CVE-2026-110264 page opens with a Critical badge and a 10 CVSS score. The CVSS panel shows two 3.1 entries, both from GitLab, and the vector is the one described above: network, low complexity, no privileges, no user interaction, changed scope and high impact on all three security properties. The page was created on October 22, 2026 and the status reads Received, which means NVD has not analyzed it yet. That is why the NVD scanner-format tab in the Affected section is empty.

The SSVC panel reads No known exploit, Automatable and Total impact. The first part will change if exploitation shows up, so watch it. The weakness is CWE-190, integer overflow or wraparound, which fits the advisory's title. The Affected section carries GitLab's own statement, a merged list of branch versions from 7.0 and 19.0 through 19.5 with a 90% confidence marker, so use GitLab's table above for the exact fixed releases, including 18.11.13. Remediation reads No guide yet, and no KEV entry is shown.

The References list has three entries: a GitLab work item, the HackerOne report tagged as technical description, exploit and permissions required, and GitLab's 19.5.1 patch release post.

What to do now

GitLab's advisory gives upgrade guidance and no workaround, so the plan starts with the upgrade.

1. Find your version and branch. Check the GitLab version in the Admin Area or the help page, and match it to the table above.
2. Upgrade to the fixed release for your branch. That means 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 or 19.5.1. If you run something older than 18.11, plan the upgrade to 18.11.13 or later.
3. Plan for the migrations. The patch includes database migrations. Single-node instances will have downtime while they run, and multi-node instances can use zero-downtime upgrades.
4. Switch on GitLab's detection rules. For self-managed installations, the advisory lists Onigmo native worker crash and Org mode render error burst, available in GitLab's security tooling repository. They look for crashes and error bursts in application logs, and a hit is a lead to investigate, not proof of an attack.
5. If you cannot upgrade today, shrink the exposure. GitLab offers no workaround, so this is general hardening and not vendor guidance: put the instance behind a VPN or an IP allowlist, and watch for worker crashes and unusual spikes in rendering errors.
6. If you see signs of compromise, treat the server's secrets as exposed. Isolate the host, keep logs, and rotate CI/CD variables, access tokens, deploy keys and runner registration tokens, since a GitLab server holds credentials for much of a team's infrastructure.

GitLab.com and GitLab Dedicated customers do not need to act on this flaw.

Takeaway

CVE-2026-110264 combines the highest score with the least public detail, and that is the situation where waiting costs the most. If you run a self-managed GitLab server, check the version today and book the upgrade, because the same release also closes two High-rated flaws. If you want to know when this CVE gains an NVD analysis, a KEV entry or a changed SSVC value, you can track it on VulnTracker and see the update as it happens.

References

Vendor: GitLab patch release 19.5.1. NVD: CVE-2026-110264. Analysis: Cyber Security News and The Hacker News.