GitLab CVE-2026-110264 Patch Explained: CVSS 10.0 Flaw Hits Every Self-Managed Version Since 2014 (World Tech)
Image: Wikimedia Commons / Markus Spiske, CC0 (illustrative photo of code on a monitor; this is not a GitLab product image — GitLab is software, and no official product photo applies).
📌 KEY HIGHLIGHTS
- The flaw: CVE-2026-110264, rated CVSS 10.0 — the maximum — an integer overflow in GitLab's regular-expression compiler that can allow unauthenticated remote code execution.
- Who must act: Anyone running self-managed GitLab Community or Enterprise Edition, every version from 7.0 onward. GitLab.com is already patched.
- The trap: If you patched on 12 October for a different 10.0 flaw, you are still vulnerable — the new fixed versions sit one patch above the October builds.
- Exploitation status: No attacks reported as of 22 October, and the flaw is not in CISA's exploited-vulnerabilities catalog — but there is no workaround, so the patch is the only certain protection.
- Scale: Censys counted about 82,000 hosts running GitLab on disclosure day; more than half run release lines old enough that they have no direct fix and must upgrade lines.
What happened?
On 21 October 2026, GitLab shipped an out-of-band critical patch release — outside its normal schedule — fixing 12 security issues at once. The headline fix is CVE-2026-110264, and GitLab took the rare step of backporting it to four release lines it no longer normally supports, because the flaw is that severe. GitLab's advisory puts it plainly: under certain conditions, the flaw "could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression."
That is the strongest possible combination for a server vulnerability: no account needed, no user interaction needed, and code execution on the server that holds your source code, your CI/CD secrets and your development history. GitLab scores it 10.0 on the CVSS 3.1 scale (network-accessible, low complexity, no privileges, no interaction, scope changed, high impact on confidentiality, integrity and availability).
Gitlab cve-2026-110264 patch explained: the flaw in plain English
The bug lives in Onigmo, the regular-expression engine built into Ruby — the programming language GitLab is written in. GitLab ships its own copy of Ruby inside its packages and patches that copy itself, which is why a weakness in this one engine reaches every GitLab release since version 7.0, from 2014.
Here is the mechanism in simple terms. A regular expression is a search pattern. When GitLab compiles a specially crafted pattern, a counter inside the engine overflows — it counts past its maximum and wraps around — corrupting memory and letting the attacker hijack the process and run their own code as the git service account. According to GitLab's own detection notes, one reachable path is a crafted Org-mode (.org) document: GitLab renders these plain-text documents with the org-ruby gem, which builds a regular expression from the keyword on a #+TODO: line without escaping it. Repeat that keyword more than 32,767 times and the counter overflows.
Two honest limits matter. First, GitLab has not said what the exact preconditions are, so no administrator can yet rule their own setup out by configuration — the company itself says the fix is the only certain protection, and its advisory offers no interim workaround. Second, a successful attempt can be quiet: it does not reliably crash the server, so you may not notice it happened.
Image: Wikimedia Commons / Florian Hirzinger, CC BY-SA 3.0 (CERN server room; illustrative photo of server infrastructure, not a GitLab installation).
Which version fixes it? The full table
Find your release line in the left column and upgrade to the version on the right. If you run anything older than 18.11, your line has no patch — the lowest fixed version is 18.11.13, so you must step up through GitLab's required upgrade stops.
| 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 (backport) |
| 19.1 before 19.1.9 | 19.1.9 (backport) |
| 19.0 before 19.0.10 | 19.0.10 (backport) |
| 7.0 through 18.11, before 18.11.13 | 18.11.13 (backport) |
One practical warning from the release notes: the 19.4.3 and 19.3.6 upgrades include database changes that run during the upgrade, which means downtime on a single-node server while they finish. Multi-node setups can apply the patch without downtime using GitLab's zero-downtime procedure — plan the window before you start, but do not let planning become delay.
The patch-again trap, and how to check for attacks
This is the detail most likely to catch teams out. On 12 October, GitLab fixed a different maximum-severity regex flaw, CVE-2026-97229, in versions 19.2.8, 19.3.5 and 19.4.2. If your instance shows one of those versions, you did the right thing nine days ago — and you are still in range for this new flaw, because the fixed builds sit exactly one patch above. Patch again, to the table above.
After upgrading, run GitLab's two published detection rules over your application logs to look back for exploitation attempts: "Onigmo native worker crash" and "Org mode render error burst." They are written in the Sigma format as part of GitLab's open-source TLDR detection framework. If either fires, treat the instance as potentially compromised: rotate secrets and review repository and pipeline integrity before calling the incident closed. If you cannot patch within the day, put the web interface behind a VPN or an IP allowlist to shrink the unauthenticated attack surface while you schedule the work.
A related follow-up worth knowing: Ruby itself shipped Onigmo fixes on 23 October in versions 4.0.9, 3.4.12 and 3.3.13. That matters for Ruby applications generally — any Ruby app that compiles regular expressions from user-controlled input sits on the same attack surface. But if you run self-managed GitLab, still apply GitLab's patch: GitLab bundles its own Ruby, and its patch is what fixes your server.
Why it matters for World readers
This is a global infrastructure story, and it lands directly on engineering teams everywhere — including the many Indian startups, enterprises and government-adjacent teams that self-host GitLab precisely to keep their code on their own servers. Self-hosting is a control choice, and this flaw turns that choice into exposure: the server you run to keep code private is reachable by anyone on the internet until it is patched.
The exposure numbers explain the urgency. Censys observed roughly 82,000 hosts and about 209,000 web properties running GitLab on disclosure day, and estimated that more than half of internet-exposed GitLab servers run a release line more than seven months old — lines with no fix of their own, whose only path is a line upgrade. Shadowserver separately tracks more than 2,700 exposed GitLab Community Edition instances. None of that means attacks have happened; it means the target population is large, and the window between disclosure and exploitation is exactly when patching matters most.
It also continues a pattern: this is the fourth code-execution flaw in GitLab's regex engine reported in a month by the same researcher, working under the handle joaxcar through GitLab's HackerOne bounty program — but the first to reach versions before 19.2. The other three (October's CVE-2026-97229 and September's CVE-2026-93577 and CVE-2026-89078) stopped at 19.2 or required a login. This one does neither.
Should you care?
✅ Verdict: If you run self-managed GitLab, this is a patch-today item — maximum severity, no login needed, no workaround, and a 12-year blast radius. ⏳ But check first: if you only use GitLab.com, or a Dedicated tenant on a patched internal build, you need do nothing — confirm that status rather than patching something that is already fixed.
Upgrade path & what to check
Do now: Identify every self-managed GitLab CE/EE instance, internet-facing ones first; upgrade to the fixed version for its release line from the table above; verify the version on each host after the upgrade. Then: run the two detection rules over logs, rotate secrets if either fires, and record before/after versions for audit. Also in this release: the same upgrade clears two high-severity flaws — CVE-2026-15723 (8.2, account takeover when OmniAuth SAML and LDAP auto-linking are both enabled) and CVE-2026-112212 (7.5, cache poisoning in OAuth/OpenID Connect discovery endpoints). Not a substitute: patching Ruby alone, or patching on 12 October, does not fix this flaw. This post will be updated if exploitation is reported or CISA adds the flaw to its exploited-vulnerabilities catalog.
Related reading on TechByCountry: the K0t edge-firewall credential-theft campaign, the CISA warning on exploited Collabora and Arista flaws, and the SafePay ransomware advisory covering 600 organisations.
FAQs
What is CVE-2026-110264 in GitLab?
It is a maximum-severity flaw, CVSS 10.0, caused by an integer overflow in Onigmo, the regular-expression engine inside the Ruby runtime GitLab uses. Under certain conditions it could let a remote attacker with no account execute code on a self-managed GitLab Community or Enterprise Edition server.
Which GitLab versions are affected and which builds fix it?
Self-managed GitLab CE and EE are affected on every release from 7.0 (2014) up to the October 21 patch. GitLab fixed it in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. GitLab.com and patched Dedicated tenants need no action.
I patched GitLab on 12 October — am I safe?
No. The 12 October release fixed a different flaw, CVE-2026-97229, in versions 19.2.8, 19.3.5 and 19.4.2. Those builds are still in range for CVE-2026-110264; upgrade again to the fixed version one patch above.
Is GitLab.com affected by CVE-2026-110264?
No. GitLab says GitLab.com already runs the fixed version, and Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 or later already include the fix. Only self-managed installations need to act.
Has CVE-2026-110264 been exploited in the wild?
Not as far as anyone has reported: GitLab reported no sign of exploitation, Censys was not aware of any as of 22 October, and the flaw was not in CISA's Known Exploited Vulnerabilities catalog as of 22 October. No public proof-of-concept existed as of 22 October — but with no workaround, waiting for exploitation reports before patching is the wrong strategy.
TAKEAWAY: A 10.0 flaw with a 12-year reach, no login requirement and no workaround leaves exactly one move: patch to the fixed version for your release line, then check your logs. If you patched on 12 October, patch again.
Follow World Tech on TechByCountry for tomorrow's update.
📸 Get tech in the last 24 hours on Instagram — follow @_techinlast24hrs for daily posts (9 AM–9 PM) and reels at 12:30 PM & 8:30 PM.
Sources
- The Hacker News — Critical GitLab Flaw (CVSS 10.0) Could Allow Unauthenticated RCE Across 12 Years of Releases
- Censys — Oct 22 Advisory: GitLab Unauthenticated Remote Code Execution (CVE-2026-110264)
- CSO Online — GitLab critical patches include one for a bug that allows code execution by unauthenticated users
- BleepingComputer via Cybernoz — GitLab warns of new max severity code execution vulnerability
- Rescana — GitLab CVE-2026-110264: Critical Unauthenticated RCE in Self-Managed GitLab CE/EE
- Lilting — GitLab CVE-2026-110264 (CVSS 10.0) Lets Unauthenticated Attackers Run Code by Rendering an .org File
- 0dayNews — Ruby Patches Regex Engine Behind Four Critical GitLab RCEs
Comments
Post a Comment