Regular expression fixes in Ruby 4.0.9 and others: how to identify affected apps

Your internal business system or membership site runs on Ruby on Rails, and its search screen or filter conditions have an input field where "regular expressions can also be used." Companies with apps like that will find it hard to put off this Ruby update. Ruby's official announcement explains that in apps that build regular expressions from strings sent by users, memory can be corrupted during the building process.

On October 23, 2026, the Ruby development team released 4.0.9, 3.4.12, and 3.3.13. The announcement opens as follows.

We have released Ruby 4.0.9, 3.4.12 and 3.3.13. They fix several bugs in Ruby’s regular expression engine (Onigmo) that GitLab found could be used for remote code execution on GitLab servers.

Based on the official announcement and the results of version checks the editorial team ran on its own Ruby, we summarize what people maintaining Ruby apps should check.

What was found

It started with GitLab. GitLab builds regular expressions entered by users, such as patterns written in CI configuration, with Regexp.new. According to the announcement, GitLab found that memory was corrupted while building crafted patterns, and that this could lead to remote code execution (RCE) on GitLab servers. GitLab applied fixes to the Ruby it bundles, addressed the issue in its own releases, and registered the following four CVEs.

• CVE-2026-89078: double free in regular expression parsing (addressed in GitLab 19.4.1)
• CVE-2026-93577: integer overflow in regular expression compilation (GitLab 19.4.1)
• CVE-2026-97229: integer overflow in CI/CD regular expression compilation (GitLab 19.4.2)
• CVE-2026-110264: integer overflow in regular expression compilation (GitLab 19.5.1)

The versions in parentheses are the GitLab versions that first fixed each CVE, as listed in Ruby's announcement. If you run GitLab itself in-house, check your GitLab version first. According to GitLab's patch release announcement, the versions that include all four fixes are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13, released on October 21. For example, in the 19.4 series, CVE-2026-110264 remains even if you have upgraded to 19.4.2. GitLab classifies CVE-2026-110264 as allowing arbitrary code to be executed on GitLab servers without authentication (CVSS 10.0). Steps for checking another GitLab vulnerability are covered in GitLab CVE-2026-85706: checking your version and steps after updating.

Apps that are affected and apps that are not

The announcement states the scope of impact clearly.

These bugs are reached only when an application compiles a regular expression from a string that an attacker controls, for example by passing it to Regexp.new, Regexp.union or Regexp.compile, or by interpolating it into a regexp literal such as /#{input}/. Applications that only use regular expressions written by their own developers are not affected.

In other words, apps that only use fixed regular expressions written in code by developers (such as /\A\d{3}-\d{4}\z/) are not affected. Affected apps are those that pass strings arriving from outside to Regexp.new, Regexp.union, or Regexp.compile, or that embed them inside a regular expression, as in /#{input}/.

The announcement also states that the following two defenses do not work in this case.

• Regexp.timeout (a limit on regular expression processing time) does not prevent it
• Limiting pattern length does not reliably prevent it. Some of the flaws occur with short patterns

Regexp.timeout is a countermeasure against patterns that take too long to process (ReDoS). This issue involves memory corruption at the stage of building the pattern, so it is a separate matter from time limits.

Which version to upgrade to

Summarizing the announcement's table as fixed versions for each series gives the following.

3.3.13 also includes the fix (resolv 0.3.2) for vulnerabilities in the bundled gem "resolv" (CVE-2026-80212, CVE-2026-80213), which were disclosed on August 27, 2026. According to Ruby's official list of branches, support for 3.3 is expected to end on March 31, 2027. If you are using 3.3, planning a migration to 3.4 or later at the same time as this update will make next year's work easier.

For cases where you cannot upgrade right away, the announcement asks you to "not build regular expressions from untrusted input."

We tried checking versions ourselves

We wrote a small script that uses the announcement's table directly for the check and ran it in the editorial team's test environment (Linux, Ruby 3.3.6).

# 2026年10月23日のRegexpの修正が入った版かを判定する（ruby-lang.orgの告知の表に基づく）
FIXED = { "4.0" => "4.0.9", "3.4" => "3.4.12", "3.3" => "3.3.13" }
series = RUBY_VERSION.split(".")[0, 2].join(".")
need = FIXED[series]
if need.nil?
  puts "#{RUBY_VERSION}: この系列には修正版が出ていない（サポート中の系列へ移行を検討）"
elsif Gem::Version.new(RUBY_VERSION) >= Gem::Version.new(need)
  puts "#{RUBY_VERSION}: 修正済み（#{need}以上）"
else
  puts "#{RUBY_VERSION}: 要更新（#{need}以上へ）"
end

On Ruby 3.3.6 in the test environment, it displayed "3.3.6: update required (to 3.3.13 or later)." We also swapped in RUBY_VERSION to check the boundary versions, and confirmed that 3.3.12, 3.4.11, and 4.0.8 are judged "update required," 3.3.13, 3.4.12, and 4.0.9 are judged "fixed," and 3.2.9 is judged "no fixed version released."

Run the check in the same environment as production, because the Ruby in use may differ between developer machines, CI images, and production servers or containers. If you run in containers, they stay on the old version until you rebuild the base image with the fixed version and redeploy. With Ruby from OS packages, the version number may not change even after a fix is incorporated, so check the package changelog (we have not checked the status of packages in each distribution this time). The steps for confirming CVE fixes in a changelog are shown, using PHP as the example, in Two unauthenticated RCE vulnerabilities in PHP.

Where to look in your own code

Even before upgrading, you can narrow down from the code which apps might be affected. The following search picks up the three methods named in the announcement and string embedding in regular expressions.

grep -rnE 'Regexp\.(new|union|compile)\(|/[^/]*#\{' app lib

We ran it against a small piece of Rails-style code made for testing (using Regexp.new(params[:q]) in a controller and /#{tag}/ in a model) and confirmed that it picked up both locations. Because this search also picks up URL path strings (such as "/users/#{id}"), you need to check each match one by one to see whether it is "a string arriving from outside." Code inside gems is not covered, so if you use a gem with a feature that treats user input as regular expressions, also check how the gem handles it.

How to fix the locations you find depends on the purpose of the feature. From here on are the editorial team's suggestions.

• If a plain string search is enough: stop using regular expressions and replace them with methods that do not build regular expressions, such as String#include? or start_with?
• If regular expression input is required as a feature: upgrade Ruby to a fixed version. Also restrict the users who can use that feature, for example to administrators

The Ruby development team says it will now discuss whether Ruby supports building regular expressions from untrusted input and how to document it. Even after applying these fixes, it is safest to keep designs that turn external strings into regular expressions on your list for review.

Caveats when tracking with vulnerability scanners

According to the announcement, the Ruby development team has not requested CVEs for these fixes as Ruby, at least for now. It advises using the four CVE numbers registered by GitLab when tracking with vulnerability scanners and similar tools. If your scanner matches CVEs by looking only at the Ruby version, these four may not be shown as "Ruby vulnerabilities." Manually adding the results of your version check to your internal vulnerability list helps prevent oversights.

Scope of verification

On October 25, 2026, we checked the ruby-lang.org news item "Regexp compilation fixes related to GitLab's CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264" (October 23), the release announcements for Ruby 4.0.9, 3.4.12, 3.3.13, and 4.0.8, the listing of the resolv vulnerability announcement (August 27), and the branch maintenance status page (document research). On October 27, 2026, we rechecked the same pages and GitLab's patch release announcements (19.4.1, 19.4.2, 19.5.1). In addition, in the editorial team's test environment (Linux, Ruby 3.3.6), we checked the version check script and the results of grep against the code made for testing (hands-on testing). We have not checked reproduction of the flaws, behavior on the fixed versions of Ruby or GitLab, the status of each OS's packages, or the NVD entries.

To review the update and maintenance setup for business systems running on Ruby, please contact us through consultation on development, AI, and automation.

References

• Regexp compilation fixes related to GitLab’s CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264（ruby-lang.org、2026-10-23）
• Ruby 4.0.9 Released（ruby-lang.org、2026-10-23）
• Ruby 3.4.12 Released（ruby-lang.org、2026-10-23）
• Ruby 3.3.13 Released（ruby-lang.org、2026-10-23）
• Ruby Maintenance Branches（ruby-lang.org）
• GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13（GitLab、2026-10-21）
• GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8（GitLab、2026-10-12）
• GitLab Critical Patch Release: 19.4.1, 19.3.3, 19.2.7（GitLab、2026-09-23）