CVE-2026-110264: a 12-year-old regex integer overflow in GitLab scores CVSS 10.0

Serious security failures in DevOps platforms often start in plain, deeply embedded utilities, not in new application logic. Regular expressions are a good example. Almost every codebase uses them for pattern matching, input validation, and text parsing. The compiler that turns a pattern into an executable state machine gets far less scrutiny. When that compiler fails to enforce strict arithmetic bounds, the resulting memory corruption can link a malformed string directly to full system compromise.

CVE-2026-110264 is a case of exactly that. It is a critical integer overflow in GitLab’s regular-expression compilation path, with a CVSS v3.1 score of 10.0. An unauthenticated attacker gets a direct route to remote code execution on affected servers.

The vulnerable code is old. It goes back to GitLab 7.0, released in 2014, so the flaw sat in the product for twelve years. Large monolithic applications that lean on legacy native extensions build up this kind of debt in their low-level parsing libraries, and it stays quiet until a capable attacker weaponizes it.

What the CVSS vector says

GitLab documents the vector as AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Read metric by metric, it describes about the worst case a defender can face.

• Network attack vector: remote actors can reach the vulnerable component over standard internet protocols. No local or physical access is needed.
• Low attack complexity: the conditions that trigger the overflow are deterministic and reproducible. The attack does not depend on race conditions, entropy states, or lucky environmental coincidences.
• No privileges and no user interaction: the attacker does not need an account, a stolen session token, or a victim who clicks a link. The server processes the payload when it arrives at the right endpoint.
• Changed scope: the flaw lives in one component, the regex compiler, but exploiting it breaks out of that component’s boundary and compromises the whole execution environment. In a web application, that means the attacker goes from crashing a text-parsing function to controlling the application server process.
• High confidentiality, integrity, and availability impact: the whole GitLab instance is exposed.

How untrusted input reaches the vulnerable code

GitLab runs on Ruby on Rails, a managed, garbage-collected environment that hides manual memory management and pointer arithmetic from developers. To handle large repositories and complex CI pipelines at acceptable speed, GitLab also relies on native C extensions and libraries compiled into the Ruby interpreter.

Ruby’s regular-expression engine, and therefore GitLab’s, is Onigmo, an optimized fork of the Oniguruma library. Pattern matching happens in many places: repository search queries, webhook validation, API filters, and the rendering of markup languages such as Org-mode. In each case the input string crosses the Foreign Function Interface boundary from the managed Ruby heap into unmanaged memory controlled by Onigmo’s C code.

The managed language’s safety guarantees stop at that boundary. The Ruby runtime assumes the C library handles its own memory safely. The C library assumes the caller will not send inputs built to break its internal arithmetic. Neither side verifies the other, and a carefully constructed string can get past high-level validation and land on the integer arithmetic that governs memory allocation inside the compiler.

How the overflow works

A regex compiler does much more than compare strings. When Onigmo receives a pattern, it runs a multi-stage pipeline that ends in optimized bytecode:

1. It parses the pattern into an Abstract Syntax Tree covering literals, character classes, alternations, and quantifiers.
2. It optimizes the tree by unrolling loops, merging adjacent character classes, and precalculating static match conditions.
3. It emits bytecode into one contiguous block of memory, which first requires calculating how large that block must be.

The size calculation typically walks the tree, counts nodes, multiplies by the size of each bytecode structure, and adds overhead for jump tables, capture group metadata, and state transitions. The integer overflow, classified as CWE-190, happens in this calculation.

Integer arithmetic in C depends entirely on the fixed width of the data types involved. Take a 32-bit unsigned integer tracking the buffer size, which tops out at roughly 4.29 GB. An attacker can write a short pattern that the optimizer expands into an internal representation needing more than that. Deeply nested repetition quantifiers or complex character class intersections can make the node count grow exponentially against the length of the source string.

When the compiler multiplies that huge node count by the instruction size, the result wraps around the 32-bit maximum and becomes a much smaller, wrong number. The compiler trusts its own result and asks the allocator for that small amount. The allocator returns a small heap buffer. The compiler then walks the tree and writes the full bytecode sequence into it, with write operations governed by the true size of the tree. It runs past the end of the buffer and spills controlled data into adjacent regions of the process heap.

From heap overflow to remote code execution

Turning a heap overflow into reliable unauthenticated remote code execution takes real work. The attacker has to understand the target’s memory layout and how the underlying allocator behaves. Modern allocators such as jemalloc and glibc malloc split the heap into chunks and keep metadata for allocation sizes, free lists, and binning.

When Onigmo overflows its buffer, the payload corrupts whatever data structure sits next to it. A sophisticated attacker would groom the heap first. By sending a series of benign, calibrated requests, they make the GitLab worker allocate and free memory in a predictable pattern, so that a valuable target, such as a Ruby object header, a C function pointer table, or an internal Onigmo structure, ends up next to the vulnerable buffer.

If the overflow overwrites a function pointer that governs execution of the compiled regex, the processor jumps to an attacker-controlled address the next time the engine runs that instruction. That hijacks the Ruby process and opens the way to arbitrary shellcode or chained return-oriented programming gadgets. I am describing the general class of technique here. This write-up does not include working exploit details.

Where Org-mode rendering fits

The threat-detection telemetry GitLab published with the advisory points to a specific entry point: the platform’s support for multiple markup formats. Repositories commonly hold documentation in Markdown, reStructuredText, and Org-mode, an outlining and authoring format popular in some developer communities. GitLab renders Org-mode through parsing libraries such as org-ruby, which translate the markup into HTML.

Org-mode files can contain dynamic tables, formula evaluation, and intricate link-matching regular expressions. If the parser relies on the Ruby regex engine to validate or extract structural components, a malicious file sends its payload straight into the Onigmo compiler. Rendering happens when a user opens a repository containing such a file. It can also happen in contexts where authentication is bypassed or no human is involved, such as webhook receivers and CI preview generators.

GitLab’s TLDR detection framework treats an “Org mode render error burst” as a primary indicator of compromise. A sudden spike in rendering failures suggests the application keeps hitting payloads that crash the native worker through memory corruption instead of triggering ordinary syntax errors.

Parser differentials make application-layer checks unreliable

One might expect the GitLab Ruby code to enforce length limits and complexity checks on user-supplied patterns before they reach Onigmo. That protection breaks down when the Ruby validator and the C compiler read the same string differently.

The gap can come from how each layer handles character encodings, escape sequences, or Unicode normalization. An attacker could craft a string that looks harmless to the validator, perhaps with multi-byte characters or escape sequences that shrink its apparent length. The Onigmo compiler may decode or unescape the same string differently and expand it into a huge internal representation. The validator is then measuring a different thing from the component that performs the dangerous memory operations, and defense in depth fails.

The reliable fix sits in the compiler. It must validate arithmetic before it executes and protect buffer allocations against wraparound.

How this differs from CVE-2026-97229

GitLab patched another maximum-severity flaw earlier this month. CVE-2026-97229 also scored CVSS 10.0 and also involved an integer overflow in the regular-expression compiler. The two disclosures landed close together, and many administrators concluded that their early-October emergency patching had closed the issue. It had not.

The two CVEs share a weakness class but affect different code paths and different version ranges:

• CVE-2026-97229 was mainly localized to CI/CD pipeline parsing, specifically how GitLab evaluates regex rules in pipeline configuration files. Remediation was largely confined to the 19.2, 19.3, and 19.4 release branches.
• CVE-2026-110264 reaches into the core rendering and validation routines and affects a much wider set of branches, including legacy deployments the earlier CI/CD flaw never touched.

An administrator who upgraded to 19.4.2 for the CI/CD vulnerability is still exposed to CVE-2026-110264 and needs a second upgrade to 19.4.3. Fixing one subsystem says nothing about the integrity of the next one.

Affected versions and the legacy upgrade problem

The affected range stretches back to GitLab 7.0, which makes this one of the harder disclosures to act on. A flaw living twelve years in a core dependency is hard to imagine in fast-moving software, but enterprise stability and backward compatibility explain it. The Onigmo compilation paths involved have been largely untouched for over a decade because they worked as intended under normal conditions. The code was functionally correct. It just lacked the adversarial testing and defensive programming needed to survive inputs designed to violate its mathematical assumptions.

For customized, air-gapped, or heavily regulated instances, upgrading is more than a package manager command. These environments often pin specific GitLab versions to stay compatible with internal integrations, custom authentication plugins, or specialized hardware. Jumping across several major release branches risks breaking workflows and demands regression testing and staging validation, which delays the fix.

GitLab acknowledged this by issuing backported patches for older branches, including version 18.11.13. Many enterprise customers cannot move to the 19.x series without unacceptable downtime, so the vendor has to keep securing codebases it would otherwise consider end of life.

Upgrade planning and database migrations

Remediation is complicated further by the database layer. GitLab’s release notes for the October 21 patches warn that the upgrades to 19.4.3 and 19.3.6 include mandatory database migrations that can cause significant downtime on single-node installations. These migrations change the PostgreSQL schema to support new security telemetry, adjust indexing strategies, or change how application state is persisted.

On a single node, the application has to go offline, the database is locked, the migrations run, and the services restart. Depending on repository data volume and schema complexity, that can take hours.

Multi-node high-availability setups and GitLab Geo deployments need a carefully orchestrated zero-downtime procedure:

1. Upgrade the database nodes first.
2. Manage the background migrations so they finish without locking critical tables.
3. Drain, upgrade, and reintroduce the application and Sidekiq worker nodes one at a time.

This keeps the service available to users, but it takes close coordination, deep knowledge of the platform’s internal topology, and careful monitoring so the cluster does not degrade mid-upgrade. Teams should plan this as incident response, not routine maintenance.

Temporary mitigations if you cannot upgrade yet

Some administrators cannot upgrade immediately because of environmental constraints or change-control delays. Compensating controls can reduce the attack surface in the meantime, with limits.

Since the attacker must submit a payload to a specific processing endpoint, restricting network access to the instance helps. Two options:

• Put GitLab behind a strict Web Application Firewall configured to drop requests with anomalous regex syntax.
• Limit access to trusted corporate IP ranges through firewall rules.

Either one can stop opportunistic scanning and automated exploitation from the wider internet. Administrators should also audit repository visibility. If the vulnerable rendering paths are mostly triggered by public documentation or unauthenticated API calls, making public repositories private or disabling public access removes the most exposed vector.

These measures only reduce risk. They do not fix the memory corruption, and they do nothing against authenticated insiders or attackers already inside the network perimeter. The fix is the vendor’s patched binaries, which correct the arithmetic in the Onigmo compiler.

Detecting exploitation attempts

Detecting active exploitation or past compromise matters as much as patching. GitLab published two threat-detection rules through its TLDR framework to help administrators hunt for indicators of compromise.

Onigmo native worker crash. This rule looks for the immediate symptom of memory corruption, the abrupt termination of a background worker. If the overflow corrupts critical memory management structures or leaves invalid function pointers, operating system memory protections typically raise a segmentation fault and kill the Ruby process. Workers crash for plenty of benign reasons, including out-of-memory conditions and ordinary bugs. A sudden, unexplained spike in native worker crashes, especially one correlated with particular repository access patterns or API requests, deserves a high-priority investigation.

Org mode render error burst. This rule targets the application-layer symptoms. An attacker probing the environment or refining heap grooming would generate a large volume of 500 Internal Server Errors as the rendering pipeline repeatedly fails on malicious Org-mode documents. Correlating these signals with web server access logs can reveal the source IP addresses, the targeted repositories, and the timestamps. That gives the forensic data needed to judge the scope of a breach and whether source code or CI secrets were exfiltrated.

What this means for dependency security

The impact reaches past GitLab administrators. Regex engines, JSON parsers, and image decoders sit inside thousands of applications, yet teams often treat them as sealed black boxes and audit them far less than the vendor’s own business logic. A library that has run for a decade without an incident gets mistaken for a secure one, when it may simply never have faced modern adversarial fuzzing aimed at deep, state-dependent memory corruption.

For open-source maintainers and the vendors who package their work, this calls for a change in testing. Checking that a parser accepts valid input and rejects malformed input is not enough. Security testing has to probe the mathematical limits of the compiler’s internal state, using coverage-guided fuzzing to generate inputs that trigger integer wraparounds, heap exhaustion, and parser differentials. Rewriting critical parsing engines in a memory-safe language such as Rust would remove whole classes of these bugs, though moving away from entrenched C codebases is a huge undertaking.

What defenders should do now

Start with the patch. Move to 19.4.3, 19.3.6, or the backported 18.11.13, depending on your branch, and plan for the migration downtime described above. If you already upgraded to 19.4.2 for CVE-2026-97229, you still need the second upgrade.

Beyond that, a security posture cannot be judged only by the vulnerabilities in an application’s own code. It has to follow untrusted data from the network edge down to the native execution layer, across every embedded dependency. A software bill of materials is worth maintaining for this reason, as a security artifact and not only for license compliance. When a foundational library like Onigmo is affected, it lets you see quickly which systems are exposed.

Apply least privilege to the application processes too. If a GitLab worker is compromised through a regex overflow, the damage depends on what that process is allowed to do. Strict filesystem limits, isolated network access, and no direct access to infrastructure credentials keep a local memory corruption flaw from becoming a compromise of the whole software delivery pipeline.

The most damaging threats do not always come from sophisticated zero-days against new attack surfaces. This one came from a simple arithmetic error in one of the oldest, most trusted utilities in the stack.