GitLab CVE-2026-110264: Critical Pre-Auth RCE Explained

Autumn 2026 was a difficult season for GitLab administrators. Patch notices arrived one after another, and several of them carried the rarest severity rating in vulnerability scoring: a perfect 10.0. Most of them pointed to the same uncomfortable place, the regular expression engine that GitLab inherited from Ruby. Security teams had barely finished one emergency upgrade before the next one landed. Servers that were patched on October 12 were already out of date nine days later.

The newest entry in that streak was CVE-2026-110264, disclosed on October 21, 2026. It allowed an unauthenticated attacker to run code on self-managed GitLab servers through a crafted regular expression, and unlike the flaw patched on October 12, it reached all the way back to GitLab 7.0.

What Is GitLab?

GitLab is a DevSecOps platform that combines Git repository hosting, CI/CD pipelines, issue tracking, code review, package registries, and security scanning in a single application. It ships as the open-source Community Edition (CE) and the commercial Enterprise Edition (EE). Organizations run it as the GitLab.com SaaS service, as the single-tenant GitLab Dedicated offering, or as self-managed installations on their own infrastructure.

GitLab is built on Ruby on Rails, so the Ruby runtime and its native libraries sit directly in the request path. A compromised GitLab server exposes far more than a code repository. It exposes CI/CD variables, deploy keys, runner tokens, cloud credentials, and the software supply chain that flows through it.

CVE-2026-110264 Vulnerability Overview

GitLab described CVE-2026-110264 as an issue that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server because of an integer overflow while compiling a specially crafted regular expression.

The reason the flaw reached so far back was the component that failed. Onigmo was Ruby’s built-in regex engine, and GitLab shipped it inside its own packages and patched it in its own builds, so the weakness existed in every release since 7.0.

Technical Analysis of CVE-2026-110264

Root Cause: A Signed 16-Bit Counter in Onigmo

Onigmo assigned an internal ID to every range-repeat quantifier in a regular expression, such as x{0,8}. The engine tracked these IDs as an int but cast them to MemNumType, a short int, when writing them into the compiled bytecode. Vulnerable versions had no range check on that conversion.

The 32,768th repeat therefore wrapped to -32768. At match time, that negative ID indexed into the repeat stack array and wrote out of bounds. The vulnerable handler was the OP_REPEAT case in regexec.c, which stored the backtracking stack index at repeat_stk[mem] using the corrupted ID.

The repeat_stk array normally lived on the thread stack via alloca(), but when a pattern’s group count exceeded MAX_PTR_NUM, Onigmo moved it to the heap with xmalloc(). A negative index then wrote data before the start of the array. In practice, this gave an attacker a controlled write into the Puma worker’s heap. The same overflow pattern also existed in Onigmo’s null-check ID counter, and the upstream fix covered both.

The Pre-Auth Entry Point: Org-Mode Rendering Through org-ruby

The bug became reachable without authentication through GitLab’s markup pipeline. GitLab rendered .org documents with the org-ruby library, and Org-mode let authors define custom TODO keywords with the #+TODO: directive. org-ruby’s headline.rb passed the keyword to Regexp.new() without escaping it, so any regex syntax inside the keyword was compiled as a live pattern.

Because GitLab rendered .org files in the anonymous blob viewer, a public project containing a crafted .org file could trigger the overflow through a request of the form GET /<project>/-/blob/main/file.org?format=json&viewer=rich, with no token, session, or cookie.

GitLab’s advisory never named this path. Independent researchers reconstructed it from the Ruby backport and the org-ruby fix, and GitLab’s own detection rule, “Org mode render error burst,” aligns with it.

Exploitation Flow

• Plant the payload. An attacker committed a .org file to a public project. Its #+TODO: keyword contained more than 32,767 range-repeat quantifiers.
• Trigger rendering. An anonymous request to the file’s rich blob viewer caused GitLab to hand the file to org-ruby for rendering.
• Compile the pattern. org-ruby’s headline parser called Regexp.new() on the unescaped keyword. Onigmo compiled the pattern, and the repeat ID counter wrapped negative.
• Corrupt memory. When the parser ran sub! against the headline text, Onigmo executed OP_REPEAT with the negative ID and wrote out of bounds into the worker’s heap.
• Crash or execute. Unshaped heap layouts produced worker crashes. A groomed heap layout could turn the controlled write into native code execution inside the GitLab process.

One precondition mattered for defenders. In the public PoC, the setup step used a token to push the crafted .org file, while the trigger step itself was a single anonymous GET request. The trigger was unauthenticated, but the payload had to land in a public project first. That was easy on instances with open self-registration, and it was also open to any user with push access or a compromised account.

Inside the Crash: Where the Write Happened

The crash trace placed the corruption inside Ruby’s String#sub!. The call ran from org-ruby’s parser (parser.rb:176) into headline.rb:100, then through rb_str_sub_bang, rb_reg_onig_match, and onig_search_gpos, and faulted in match_at at regexec.c:3836, the out-of-bounds write. The compile step only planted the corrupted ID. The damage happened when the pattern executed.

Exploitation attempts left two distinct signatures:

• Worker crashes. Testing produced SIGSEGV and SIGILL signals, with crash addresses changing after each worker respawn. The SIGILL result showed the write had reached executable memory or a function pointer.
• Render timeouts. A separate PoC against GitLab CE 19.3.1 placed about 35,000 repeated regex units in a #+TODO: keyword and recorded slow rendering and a Timeout::Error in exceptions_json.log.

From Memory Corruption to Code Execution

No verified public RCE chain existed for CVE-2026-110264 at the time of writing. A closely related bug, however, showed the class was weaponizable. Rapid7’s analysis of the October 12 Onigmo bug, CVE-2026-97229, reliably achieved command execution as the git user on the official gitlab/gitlab-ce:19.4.1-ce.0 image with ASLR enabled. Code execution as git would give an attacker access to every repository, CI/CD secret, and integration credential the instance held.

How the Fix Worked

Ruby added the range check in PR #16801 in April 2026. The patch made compile_range_repeat_node() return ONIGERR_TOO_MANY_RANGE_REPEAT when the cast ID reached zero or below, applied the same check to null-check IDs, and raised a RegexpError at compile time. The change landed only on Ruby’s main branch at first, so the Ruby 3.3, 3.4, and 4.0 builds bundled with GitLab did not include it. GitLab backported the patch into its bundled Ruby for the October 21 release. Separately, org-ruby added Regexp.escape() to custom TODO keywords in PR #112, so regex metacharacters in keywords were treated as plain text.

The fixes were not identical across branches. GitLab’s changelog listed a “Ruby regexp repeat ID overflow patch for 3.3, 3.4 and 4.0” for 19.2 and later, while 19.1.9, 19.0.10, and 18.11.13 listed a “Ruby regexp repeat-range double-free patch for 3.3 and 3.4.” All seven branches also updated gitlab-markup to 2.2.0 and rdoc to 8.1.0. GitLab did not explain the difference, which made runtime-level verification more important.

Exploit Activity

According to independent researcher al4n4n, a test of 50 anonymous requests against a vulnerable container returned 4 HTTP 502 responses and 3 worker restarts, with three SIGSEGV crashes and one SIGILL crash logged in puma_stderr.log. The same research found that all tested Docker images reported the same ruby -v output, so version strings alone could not confirm a fix. The reliable checks were compiling the pattern or searching libruby for the new error string.

Additional public repositories followed:

• One repository published on October 22 described itself as a crash-level proof of concept that showed memory corruption without reaching code execution.  
• A Python PoC from googlesky appeared on October 24, packaged with a Nuclei template that fingerprinted GitLab versions.  
• One repository claimed code execution, but that claim had not been independently verified.
• The Masriyan repository stated that its script had not been validated as a working trigger, made authenticated API requests, and did not show that GitLab compiled the submitted input as a vulnerable regex.

Affected and Fixed Versions of GitLab:

Two notes matter for patch planning:

• Servers patched on October 12 to 19.4.2, 19.3.5, or 19.2.8 for CVE-2026-97229 remained vulnerable to CVE-2026-110264.
• The older-branch releases (19.2.9, 19.1.9, 19.0.10, and 18.11.13) included only the critical fix. Fixing all 12 issues in the release required 19.3.6, 19.4.3, or 19.5.1.

Mitigation and Detection

1. Patch Immediately

Upgrade all self-managed instances to a fixed version, prioritizing internet-facing servers. GitLab noted that single-node instances would experience downtime during the upgrade because database migrations had to finish before GitLab started, while multi-node deployments could apply the patch with zero-downtime procedures.

2. Reduce Exposure Until Patched

GitLab published no official workaround. GitLab’s detection guidance suggested reducing public visibility where possible until patching, which narrowed the unauthenticated path without closing the flaw. Further compensating steps included:

• Disabling open self-registration
• Restricting who could create public projects
• Disabling public visibility at the instance level

3. Verify the Fix

Do not rely on version strings alone. Confirm the patched bundled Ruby by compiling a test pattern that exceeds the repeat limit (it should raise a RegexpError) or by checking libruby for the new error string. Patched Ruby versions corresponded to 3.3.13, 3.4.12, and 4.0.9.  

4. Hunt for Exploitation Attempts

• Deploy GitLab’s two Sigma rules, “Onigmo native worker crash” and “Org mode render error burst,” published in its open-source TLDR framework.
• Search /var/log/gitlab/puma/puma_stderr.log for [BUG] Segmentation fault entries that reference org-ruby or headline.rb.
• Review exceptions_json.log for Timeout::Error events raised during .org rendering.
• Search web logs for anonymous requests to .org blobs with viewer=rich followed by HTTP 502 responses or worker restarts.
• Audit public repositories for .org files with abnormally long #+TODO: lines.
• Monitor for unexpected child processes or outbound connections from the git service account.
• If exploitation is suspected, follow with a credential review and rotate CI/CD variables, runner tokens, deploy keys, and personal access tokens.

Timeline of CVE-2026-110264

Conclusion: The Danger Lived in a Dependency

CVE-2026-110264 showed that the most dangerous code in an application was not always code its developers wrote. A regex engine bundled inside a language runtime and an unescaped string inside a markup library combined into a pre-auth RCE that went unnoticed through twelve years of GitLab releases. The bug was also the latest in a rapid run of Onigmo flaws, which showed that researchers had found a productive attack surface and that attackers were watching the same patch notes. The lesson was clear. Organizations that ran self-managed GitLab needed to treat the platform as crown-jewel infrastructure, patch it on a critical timeline, verify the fix at the runtime level, and audit every place user content reached a parser.

Loginsoft Vulnerability Intelligence (LOVI) helps security teams stay ahead of vulnerabilities like CVE-2026-110264 by tracking disclosures, PoC releases, exploitation signals, and KEV additions in real time, and by delivering prioritized, actionable intelligence before n-day exploitation begins.

FAQs

Q1. What is CVE-2026-110264?

CVE-2026-110264 is a CVSS 10.0 integer overflow in Ruby’s Onigmo regex engine, as bundled with GitLab CE and EE. It allowed unauthenticated remote code execution on self-managed GitLab servers.

Q2. How is CVE-2026-110264 triggered?

A crafted #+TODO: keyword in a .org file inside a public project overflowed Onigmo’s repeat ID counter when GitLab rendered the file for an anonymous visitor.

Q3. Which GitLab versions are affected by CVE-2026-110264?

All self-managed versions from 7.0 before 18.11.13, plus 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1.

Q4. Is GitLab.com affected?

No. GitLab.com and GitLab Dedicated were already patched.

Q5. How can I check whether GitLab is patched for CVE-2026-110264?

Upgrade to a fixed version, then verify the bundled Ruby rejects oversized repeat patterns with a RegexpError. Version strings alone are not reliable for Docker images.

Q6. Is CVE-2026-110264 exploited in the wild?

No confirmed exploitation or CISA KEV listing had been reported as of October 28, 2026. Crash-level PoCs are public.

Q7. Is there a workaround for CVE-2026-110264?

No official workaround exists. Upgrading is the only complete fix. Reducing public project visibility and disabling open registration narrow the attack path in the meantime.