How to Fix the Ruby Onigmo Regexp Bugs in Your Apps

To fix the Ruby Onigmo regexp bugs behind GitLab's October 2026 CVEs, upgrade every Ruby runtime to 4.0.9, 3.4.12 or 3.3.13 or later. The bugs only matter where an application compiles a regular expression from a string an attacker controls, so the second job is finding that code. Ruby's own advice for anything you cannot upgrade is blunt: stop compiling regular expressions from untrusted input. Timeouts and pattern length limits do not reliably help.

Why this matters outside GitLab

GitLab found that crafted patterns could corrupt memory while Ruby compiled them, and assigned four CVEs for it. One of them, CVE-2026-97229, is now in CISA's Known Exploited Vulnerabilities catalog, as covered in our news report on the GitLab CI regex flaw. GitLab fixed its own product by patching the Ruby it ships. Every other Ruby application on your network still depends on whatever Ruby it runs on.

CISA's catalog entry says other products can potentially be affected by the same underlying Ruby and Onigmo issue. That makes this a platform patch, not just a GitLab patch.

What are the Ruby Onigmo regexp bugs?

They are memory corruption bugs in Onigmo, the regular expression engine built into Ruby, that trigger while Ruby compiles a pattern rather than while it matches text. A crafted pattern can corrupt memory during compilation, and GitLab showed that this can lead to remote code execution.

The Ruby team's advisory of 23 October 2026 maps each GitLab CVE to a Ruby change:

• CVE-2026-89078: a double free when parsing a pattern fails after an alternation. Fixed in Ruby 4.0.0, 3.4.12 and 3.3.13.
• CVE-2026-93577 and CVE-2026-97229: an integer overflow in the size of a compiled pattern. Fixed in Ruby 4.0.8, 3.4.12 and 3.3.13.
• CVE-2026-110264: an overflow of internal IDs in a pattern with many repeats. Fixed in Ruby 4.0.9, 3.4.12 and 3.3.13.

Ruby 4.0.9, 3.4.12 and 3.3.13 contain all of these fixes. Ruby 3.3 is in security maintenance, and the team shipped 3.3.13 as an exception because GitLab assigned CVEs to these issues. If you want the background on the integer overflow class, see what an integer overflow vulnerability is.

How do you know if an application is affected?

An application is affected if it builds a regular expression from a string that an outside party can control. Applications that only use patterns written by their own developers are not affected.

The Ruby advisory names the code paths to look for:

• Regexp.new called with user input
• Regexp.union called with user input
• Regexp.compile called with user input
• user input interpolated into a regexp literal, such as /#{input}/

Typical places this shows up: search features that accept a "regex mode", admin screens for filter or routing rules, log and alert pipelines with user-defined match patterns, CI and automation tools that read patterns from configuration files, and chat or ticketing bots with custom triggers.

How to fix the Ruby Onigmo regexp bugs, step by step

1. Inventory every Ruby runtime

List each place Ruby runs: system packages on servers, version-manager installs on build hosts, container base images, and products that ship their own embedded Ruby. Record the exact Ruby version for each one. Container images are the easiest to miss, because the running version is whatever was current when the image was built.

2. Upgrade to a fixed release

Move each runtime to Ruby 4.0.9, 3.4.12 or 3.3.13, or later in the same series. For Ruby 4.0, note that 4.0.8 is not enough: the fix for CVE-2026-110264 first appears in 4.0.9.

If you use your Linux distribution's Ruby package, check the distribution's security tracker to see whether it backported the Onigmo fixes. A distribution package can carry the fix under an older version string, or lack it under a newer one.

3. Rebuild and redeploy containers

Updating a base image does not change containers that are already running. Rebuild application images on the patched base, redeploy them, and confirm the running containers report the new Ruby version.

4. Ask vendors about embedded Ruby

For commercial or open source products that bundle Ruby, the vendor has to ship the fix. GitLab did this in 19.4.1, 19.4.2 and 19.5.1. For anything else, open a ticket and ask whether the product compiles user-supplied patterns and which release carries the patched Onigmo.

5. Find code that compiles untrusted patterns

Search your Ruby codebases for the four patterns listed above and review each hit. For every place where the pattern can come from a user, decide whether it is needed at all. Often the feature can use a plain substring match, a fixed list of allowed patterns, or escaped input.

6. Fix scanner blind spots

The Ruby team has not requested CVE IDs of its own for these fixes, at least for now. Its advisory asks people to track the issues by GitLab's CVE IDs, for example in a security scanner. A scanner that only checks Ruby packages against Ruby CVEs may therefore show a vulnerable runtime as clean. Add a custom check for Ruby versions below the fixed releases.

What does not work as a mitigation?

Regexp.timeout does not protect against these bugs, and limiting the length of patterns does not reliably protect against them either. The memory corruption happens while the pattern compiles, and some of the bugs can be triggered by short patterns.

That rules out the two controls most teams already have for regular expression denial of service. If you cannot upgrade a runtime, the only mitigation the Ruby team offers is to avoid compiling regular expressions from untrusted input.

How do you verify the fix?

Confirm that every runtime in your inventory reports a fixed version, that rebuilt containers are the ones actually running, and that vendor products are on releases that state they include the Onigmo fixes.

Keep the inventory from step 1. The broader design question, whether user-supplied patterns belong in your applications at all, is covered in why untrusted regex patterns are a code execution risk.