# Ruby Regexp: four critical vulnerabilities disclosed by GitLab.

Source: https://libwatch.com/en/cve/ruby-regexp

Critical alert · Ruby and GitLab

- CVSS up to 10
- Remote code execution
- Fixed Oct 23, 2026

A crafted regular expression corrupts Ruby's memory while it is being compiled, up to code execution on the server. GitLab is affected, as is any Ruby application that compiles a pattern supplied by a user. Here is how to tell whether you are affected, and how to fix it.

[Check my Ruby projects](https://app.libwatch.com/users/sign_up?source=cve_ruby_regexp)

[See the commands](#verifier)

Updated October 23, 2026 · Sources: ruby-lang.org, GitLab

## Fact sheet

As of Oct 23, 2026

CVE CVE-2026-89078
CVE-2026-93577
CVE-2026-97229
CVE-2026-110264

Severity CVSS 3.1 from 9.9 to 10 · critical

Impact Remote code execution on the server

Origin Onigmo, Ruby's regular expression engine

Ruby fixed in 4.0.9 · 3.4.12 · 3.3.13

GitLab fixed in 19.5.1 · 19.4.3 · 19.3.6 · 19.2.9
19.1.9 · 19.0.10 · 18.11.13

Found by joaxcar, through GitLab's bug bounty program

## The essentials in 60 seconds

### The danger is in Regexp.new.

Only applications that compile a regular expression from text an attacker controls are exposed.

### Regexp.timeout doesn't protect you.

Neither Ruby's timeout nor a limit on pattern length stops these bugs: they strike during compilation.

### GitLab: update the instance.

GitLab ships its own Ruby. On a self-managed instance, it's the GitLab package that has to be updated.

What's happening

## Four memory bugs in regular expression compilation

Numbered and scored by GitLab, which fixed them in its product before Ruby released its own versions.

| CVE | The bug | Access required | CVSS | GitLab fixed in |
| --- | --- | --- | --- | --- |
| CVE-2026-89078 | Double free in the pattern parser | A GitLab account | 9.9 | 19.4.1 · Sep 23, 2026 |
| CVE-2026-93577 | Integer overflow in the pattern compiler | A GitLab account | 9.9 | 19.4.1 · Sep 23, 2026 |
| CVE-2026-97229 | Integer overflow in the compiler, through the CI/CD configuration | None | 10.0 | 19.4.2 · Oct 12, 2026 |
| CVE-2026-110264 | Integer overflow in the pattern compiler. Affects GitLab 7.0 to 19.5 | None | 10.0 | 19.5.1 · Oct 21, 2026 |

The Ruby team hasn't requested its own CVEs for these fixes yet, and says it may come back to it.

Who is affected

## Your Ruby branch, and what to do

Support dates for each branch come from the official ruby-lang.org schedule.

| Branch | Fixed in | Official support | What to do |
| --- | --- | --- | --- |
| 4.0 | 4.0.9 | Normal maintenance | Update to 4.0.9 |
| 3.4 | 3.4.12 | Normal maintenance | Update to 3.4.12 |
| 3.3 | 3.3.13 | Security only → Mar 31, 2027 | Update to 3.3.13, a release made as an exception |
| 3.2 and earlier | none | Ended Apr 1, 2026 | Migrate to 3.3 at least, ideally 3.4 or 4.0 |

Ruby 3.2 won't get a fix

It reached end of life on April 1, 2026: it no longer gets any fixed release, neither for these vulnerabilities nor for the next ones.

Check in 2 minutes

## Look in three places: the version, the code and GitLab

The version tells you whether Ruby is patched. The code tells you whether the application compiles patterns that come from outside.

The Ruby version

```
$ cat .ruby-version
$ grep -A1 'RUBY VERSION' Gemfile.lock
$ ruby -v
```

Patterns compiled on the fly

```
$ grep -rnE 'Regexp\.(new|compile)|/#\{' app lib
```

Your GitLab instance

```
$ sudo gitlab-rake gitlab:env:info | grep -i version
```

What LibWatch does for you

## The Ruby version of every repository, rechecked every night.

- Reads the Ruby version pinned in each repository: .ruby-version, Gemfile.lock, .tool-versions or mise.
- Flags when a newer version of the branch exists, and when the branch is no longer supported, like Ruby 3.2.
- Rechecks everything every night, even projects nobody touches.

Its limit: LibWatch doesn't yet link these CVEs to the Ruby engine, and doesn't monitor the version of your GitLab instance. Also check ruby -v in production.

[Try LibWatch for 14 days](https://app.libwatch.com/users/sign_up?source=cve_ruby_regexp)

Your code stays with you: LibWatch reads your dependency files and only keeps the list of your packages. [How it works →](/en/security)

Fix

## Three steps, and the second is the one people forget

Only updating Ruby fixes all four vulnerabilities.

### Update Ruby, then rebuild your images

Also change .ruby-version and the ruby line of the Gemfile, then update Gemfile.lock.

rbenv, Bundler and Docker

```
$ rbenv install 3.4.12 && rbenv local 3.4.12
$ bundle update --ruby
$ docker build --pull --no-cache -t mon-app:corrigee .
```

### Restart every Ruby process

Puma, Sidekiq, Solid Queue… A process started before the update still runs on the old Ruby.

Check

```
$ ps -eo pid,lstart,cmd | grep -E 'puma|sidekiq|solid'
```

### Self-managed GitLab: update the package

To 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. Updating the system Ruby doesn't fix GitLab's.

Omnibus (Debian / Ubuntu)

```
$ sudo apt update && sudo apt install gitlab-ee
# Community Edition: gitlab-ce
```

In the meantime

## If you can't update right away

Protects

### Stop compiling patterns that come from users

- — To search for text, String#include? is enough: no pattern is compiled.
- — For a filter, offer a list of predefined patterns rather than an open text field.

Ruby

```
# instead of
lignes.grep(Regexp.new(params[:q]))
# prefer
lignes.select { _1.include?(params[:q]) }
```

Doesn't protect

### What doesn't protect you

- — Regexp.timeout: the bugs strike during compilation, before the pattern ever runs.
- — Limiting pattern length: not reliable, according to the Ruby team.

Only the update fixes it

The Ruby team recommends 4.0.9, 3.4.12, 3.3.13 or later.

Timeline

## One month, from the first CVE to Ruby's fix

Sep 23, 2026

### GitLab 19.4.1

First two CVEs fixed, scored 9.9.

Oct 12, 2026

### GitLab 19.4.2

A CI/CD vulnerability exploitable without an account, scored 10.

Oct 21, 2026

### GitLab 19.5.1

The last CVE, affecting GitLab 7.0 to 19.5, scored 10.

Oct 23, 2026

### Ruby 4.0.9, 3.4.12, 3.3.13

The fixes land in Ruby, for every application.

Frequently asked questions

## What people have been asking us since October 23

### Is my Rails application affected?

Only if it compiles a regular expression from text a user controls: Regexp.new(params[…]) or an interpolation in a literal. Look for these patterns in your code, and update Ruby anyway.

### Why do the CVEs come from GitLab and not from Ruby?

The vulnerabilities were reported by joaxcar through GitLab's bug bounty program. GitLab numbered, scored and fixed them in its product before Ruby released its own versions. The Ruby team hasn't requested its own CVEs for these fixes yet, and says it may come back to it.

### Isn't Regexp.timeout enough?

No. The bugs strike while the pattern is being compiled, before it ever runs: neither Ruby's timeout nor a limit on pattern length stops them. Only updating to 4.0.9, 3.4.12, 3.3.13 or later fixes them.

### Does LibWatch need access to my code?

No. LibWatch reads your dependency files and only keeps the list of your packages. Its limit: LibWatch doesn't yet link these CVEs to the Ruby engine, and doesn't monitor the version of your GitLab instance. Also check ruby -v in production.

## Sources

Checked on Oct 23, 2026.

- [ruby-lang.org · Announcement of Oct 23, 2026](https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/)
- [ruby-lang.org · Ruby branches](https://www.ruby-lang.org/en/downloads/branches/)
- [GitLab 19.4.1 · Sep 23, 2026](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-1-released/)
- [GitLab 19.4.2 · Oct 12, 2026](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)
- [GitLab 19.5.1 · Oct 21, 2026](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/)
- [cve.org · 4 records](https://www.cve.org/CVERecord?id=CVE-2026-89078)