GitLab's October 2026 Regex Vulnerability Explained: Patch GitLab and Ruby

The server can be taken over by the pattern alone. In the GitLab regex vulnerability of October 2026, a specially crafted regex corrupts memory while Ruby turns it into a program, before it ever searches any text.

Picture a common setup. A software team in Pune runs its own GitLab server for 60 developers, and also builds a Rails support tool where agents type regex filters for tickets. The setup is made up, but both risks are real.

The team now has two jobs. Upgrade GitLab, which ships its own patched Ruby, and check whether the support tool compiles patterns that customers or agents type. This guide walks through both on that one setup.

• Regex (regular expression): a small pattern language for matching text. The pattern ^ERR\d+ matches lines that start with ERR and then digits. A | in a pattern means or, as in cat|dog.
• Compiling a regex: turning the pattern text into a small program of instructions that the engine runs later. In Ruby, Regexp.new does this.
• Onigmo: the regex engine built into Ruby. Every Ruby regex, including those inside GitLab, is compiled and run by Onigmo.
• CVE: a public ID number for one security bug, such as CVE-2026-110264. CVSS is a 0 to 10 severity score; this one scores 10.0.
• Self-managed GitLab: a GitLab server you install and run yourself, as the Pune team does, instead of using GitLab's hosted service.

The GitLab regex vulnerability is a critical bug where compiling a specially crafted regular expression overflows an integer and can let an unauthenticated user run code on the GitLab server. GitLab rates it CVSS 10.0.

An integer overflow happens when a number grows past the largest value its storage can hold and wraps around, like an odometer rolling back to zero. The engineer section below shows it running.

GitLab fixed it in a critical patch release on 21 October 2026. Every GitLab version from 7.0 up to the fixed releases is affected, so almost any self-managed server that has not upgraded since then is exposed.

It is the last of four related CVEs. GitLab fixed CVE-2026-89078 and CVE-2026-93577 in 19.4.1 and CVE-2026-97229 in 19.4.2, all bugs in how Ruby builds patterns, according to the Ruby team's advisory.

The 4.0.0 entry means Ruby 4.0 already had that one fix when it first shipped, so on Ruby 4.0 the other two fixes arrived in 4.0.8 and 4.0.9.

You are affected if your software compiles a regex from text an attacker controls, and your Ruby is older than 4.0.9, 3.4.12 or 3.3.13. Apps that only use patterns written by their own developers are not affected, says the Ruby advisory.

The Ruby team names four ways in. Three are methods: Regexp.new, Regexp.compile and Regexp.union. The fourth is dropping text into a pattern written in the code, as in /#{input}/.

GitLab, the Ruby team writes, uses Regexp.new on patterns its users write, such as those in CI configuration, the file that tells GitLab how to build and test code.

Upgrade GitLab to the fixed release in your series. The Ruby advisory says GitLab fixed these issues by patching the Ruby it ships, so a Linux package install gets the fix with the upgrade.

1. 1

   Find your GitLab version

   On a Linux package install, run sudo gitlab-rake gitlab:env:info on a node that runs GitLab Rails. Read the Version line under GitLab information.

2. 2

   Pick the target release

   Match your series in the table above. If you run an older series than 18.11, you need a version upgrade to a supported series, not only a patch.

3. 3

   Plan for migrations

   GitLab says 19.4.3 and 19.3.6 include database migrations, so single-node instances on those series will have downtime. Multi-node setups can avoid downtime with GitLab's zero-downtime upgrade steps. Take a backup first.

4. 4

   Upgrade and restart

   Install the new package the way you normally upgrade. On a multi-node setup, follow GitLab's documented upgrade order.

5. 5

   Check that it worked

   Run gitlab:env:info again. The Version line should show the fixed release or later, for example 19.5.1-ee on Enterprise Edition.

# Linux package (Omnibus) install
sudo gitlab-rake gitlab:env:info

# Self-compiled install, from the GitLab directory
bundle exec rake gitlab:env:info RAILS_ENV=production

A self-compiled install is different. GitLab's install docs tell you to install Ruby yourself from source, and the patch notes give no separate steps for it. Upgrade that Ruby too, to the fixed release on a branch your GitLab version supports, and check the Ruby Version line.

GitLab's install docs still list Ruby 3.2.x as the minimum, as of 24 October 2026. The Ruby advisory lists no fix for 3.2, so a source install sitting on 3.2 needs a newer Ruby.

GitLab also lists two detection names for self-managed instances: Onigmo native worker crash and Org mode render error burst. GitLab released these detections for self-managed instances, and they are listed on the patch page. Treat a sudden burst of either as a reason to look closer, but patch first.

First find where your code compiles patterns, then decide whether the text can come from a user. A plain text search over the code base is a good start, not a full audit.

grep -rnE 'Regexp(\.|::)(new|compile|union)|/#\{|%r\{[^}]*#\{|\.match\??\(' app lib config 2>/dev/null

We ran this on a small sample file from the support tool. It found four lines: a Regexp.new on a user's rule, an escaped interpolation, a Regexp.union of strings and a raw interpolation of user text. The 2>/dev/null part hides errors for folders you do not have.

The search also flags .match and .match? calls. In our tests on Ruby 3.3.6, a string passed to match or match? was compiled as a pattern, so "axb".match?("a.b") returned true. The advisory does not list these, but they compile text too.

Then check the Ruby version that actually runs the app, inside the container or on the server. Run ruby -v there; you need 4.0.9, 3.4.12 or 3.3.13 or later on your branch.

Compiling is a separate step from matching, and all three bugs live in that first step, in the parser and the compiler. Onigmo reads the pattern, builds a tree of its parts, then writes a program of instructions into memory.

If a size or ID count wraps around during that build, the engine can write or jump to the wrong place in memory. GitLab says this could lead to arbitrary code execution. Corrupted memory is a common route attackers use to take control of a process.

Integer overflow in plain numbers

Think of a car's odometer with six digits. After 999999 km it shows 000000, and anyone reading it thinks the car is new. A computer integer does the same at its own limit.

A signed 32-bit integer tops out at 2,147,483,647, which engineers call INT_MAX. Add one and it becomes a large negative number. You can see this safely in Ruby:

max = 2**31 - 1
puts "INT_MAX = #{max}"
wrapped = [max + 1].pack("l").unpack1("l")   # store the value in a signed 32-bit slot
puts "INT_MAX + 1 in 32 bits = #{wrapped}"

On Ruby 3.3.6 this prints INT_MAX = 2147483647, then INT_MAX + 1 in 32 bits = -2147483648. Ruby's own integers grow without limit, so the pack call forces the value into a 32-bit slot, like the fixed-size numbers inside Onigmo's C code.

Where the picture breaks: an odometer only misleads a buyer. Inside a compiler, a wrapped number can decide how much memory to set aside or where to jump, so the program can write past the space it planned.

What the public fixes show

Pull request 19020, merged on 25 September 2026, explains the size overflow in its description. A nested bounded repeat multiplies two counts as an int, the product wraps, and a safety check passes for a repeat far larger than allowed.

The same description says long chains of repeats can push the compiled program past INT_MAX, which wraps the jump offsets stored inside it. The fix compares by division, which cannot overflow, and caps the program size as it is written.

Pull request 16801, the fix behind CVE-2026-110264, is titled Reject overflowed repeat/null-check IDs in huge regexps. It adds explicit errors when a pattern needs too many internal IDs for repeats, instead of letting the counter wrap.

Pull request 13332 fixes a double free, where a program hands the same block of memory back twice. Its description says the old code could free the same parse node twice when parsing and compiling a pattern hit an error.

Its title mentions too big repetition quantifiers, while the advisory describes the trigger as a parse failure after an alternation. Both point at error paths in the same code.

Most features do not need user-written regexes at all. If users want to find a word or phrase, match it as plain text, and the special characters lose their meaning.

input = "price (in Rs.)?"
safe = Regexp.new(Regexp.escape(input))
puts safe.source                                  # price\ \(in\ Rs\.\)\?
puts safe.match?("total price (in Rs.)? 500")    # true
puts "total price (in Rs.)? 500".include?(input)  # true, no regex at all
puts Regexp.union("a.b", "c|d").source             # a\.b|c\|d

We ran these lines on Ruby 3.3.6 and got the outputs in the comments. Regexp.escape puts a backslash before each special character, and Regexp.union escapes plain strings the same way.

An escaped pattern has no repeats or alternation, the parts these three fixes deal with. The Ruby advisory does not discuss escaped input, so upgrade Ruby anyway. Simplest of all, String#include? avoids the regex engine entirely.

Watch for Regexp.union given Regexp objects: those are used as they are, not escaped. And /#{text}/ with raw text compiles that text as a pattern, so a user can type any pattern into it.

If users really must write patterns

Some features need real patterns, such as log filters or CI rules. The Ruby team's own advice, if you cannot upgrade, is to avoid compiling regexes from untrusted input at all.

• Upgrade Ruby first. That is the only fix the Ruby team recommends for these bugs.
• Limit who can create patterns. A pattern field open to anyone on the internet is a bigger risk than one only admins can edit.
• Compile untrusted patterns in a separate, short-lived worker process with few privileges. A crash or takeover then hits a box with nothing valuable in it.
• Log compile errors and crashes. A RegexpError is normal for a typo, but a crash in the regex engine is not.

Regexp.timeout limits how long matching may run, and these bugs happen while compiling. The Ruby advisory states plainly that Regexp.timeout does not protect against them, and that length limits do not reliably help either.

Pause and predict: the code below sets Regexp.timeout to 0.05 seconds. It then compiles a long, harmless 2.2 MB pattern and matches a tiny, slow one. Which of the two does Ruby stop?

Regexp.timeout = 0.05
pat = "(?:abc|abd)" * 200_000            # long but ordinary
t = Process.clock_gettime(Process::CLOCK_MONOTONIC)
re = Regexp.new(pat)                       # compile: the timeout is not checked here
puts Process.clock_gettime(Process::CLOCK_MONOTONIC) - t

slow = Regexp.new('^(a|a)*\1$')            # backreference, so the match cache is off
begin
  slow.match?("a" * 40 + "b")
rescue Regexp::TimeoutError => e
  puts e.class                             # Regexp::TimeoutError
end

On Ruby 3.3.6, compiling the harmless pattern took 0.24 seconds and raised no error. Matching the slow pattern raised Regexp::TimeoutError after 0.051 seconds. Timings vary by machine.

What just happened? The compile step ran past the time limit and finished anyway. Only the match step checked the clock, so a bug that fires while compiling never meets the timeout.

Length limits fail for a different reason. The advisory says some of these bugs can be triggered by short patterns, so a 200-character cap can still let a dangerous pattern through.

The Ruby team says it has generally treated compiling a regex from untrusted input as unsafe, so it is still deciding whether these count as Ruby vulnerabilities. As of 23 October 2026, it has not requested CVE IDs.

The advisory also points to precedent. Ruby did treat a double free in regex compiling as a vulnerability in CVE-2022-28738, after a full assessment, and did the same for CVE-2024-27282.

The advisory also admits a gap in the docs. Ruby's Regexp documentation discusses untrusted patterns only as a denial-of-service risk and recommends a timeout. It does not say whether compiling untrusted patterns is supported.

For now, the Ruby team asks you to track these fixes by GitLab's CVE IDs, for example in a security scanner. A scanner that looks only for Ruby CVEs may miss them, so check your Ruby version by hand too.

Ruby 3.3 is in security maintenance, where releases normally carry only vulnerability fixes. The team made an exception for 3.3.13 because GitLab assigned CVEs to issues that rely on these changes.

A regex is a tiny program, so a user-written regex is user-written code. Any feature that compiles it inherits every bug in the compiler, not just the risk of a slow match.

The same lesson shows up with template engines, query languages and spreadsheet formulas. Give users the smallest language that does the job, run the risky part with few privileges, and keep the runtime patched.

At least two of the bugs came through GitLab's bug bounty. The Ruby advisory credits Johan Carlsson for the overflow fixed by pull request 19020, and GitLab's patch notes thank the same researcher, joaxcar, for CVE-2026-110264.

1. 1

   Name the trust boundary

   Say that any feature letting users submit patterns treats user text as a small program. Mark the compile step as untrusted work.

2. 2

   Separate the two risks

   Slow matching (ReDoS) is handled with timeouts. Memory bugs during compiling need patched runtimes and isolation, as GitLab's October 2026 fix showed.

3. 3

   Prefer a smaller feature

   Offer plain-text search or a fixed set of filters first. Allow full patterns only where the product truly needs them.

4. 4

   Isolate what remains

   Compile and run user patterns in a separate worker with few privileges and strict resource limits, so a crash cannot reach secrets.

5. 5

   Plan patching and detection

   Track runtime versions across the fleet, alert on regex engine crashes, and rehearse a same-day upgrade for critical fixes.