Ruby 4.0.9, 3.4.12 and 3.3.13 Fix Regexp Compiler Bugs Behind Four GitLab CVEs, and the Ruby Project Has Not Requested CVE IDs of Its Own
Ruby's October 23 releases fix Onigmo regular expression bugs that GitLab found could lead to remote code execution; Ruby says it has not requested CVE identifiers for them.
Overview
The Ruby project released Ruby 4.0.9, 3.4.12 and 3.3.13 on October 23, 2026. According to Ruby’s security post, the releases fix several bugs in Ruby’s regular expression engine (Onigmo) that GitLab found could be used for remote code execution on GitLab servers. GitLab published four CVEs for these issues, and the Ruby releases contain the fixes for the underlying bugs in Ruby.
What Ruby Fixed
The Ruby post maps each GitLab CVE to a bug in Ruby and to a change that fixes it:
- CVE-2026-89078: a double free when parsing a pattern fails after an alternation (change #13332). Ruby lists 4.0.0 as the first 4.0 release containing the fix, and 3.4.12 and 3.3.13 for the older series.
- CVE-2026-93577 and CVE-2026-97229: an integer overflow in the size of a compiled pattern (change #19020). The first 4.0 release containing the fix is 4.0.8.
- CVE-2026-110264: an overflow of internal IDs in a pattern with many repeats (change #16801). The first 4.0 release containing the fix is 4.0.9.
The post states that Ruby 4.0.9, 3.4.12 and 3.3.13 contain all of these fixes. The Ruby 3.4.12 announcement describes the release as including “fixes for bugs in Regexp compilation that GitLab’s CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264 rely on.”
Ruby says Johan Carlsson (joaxcar) discovered the integer overflow fixed by #19020 through GitLab’s bug bounty program.
The GitLab Side
GitLab shipped its own patches earlier. Per GitLab’s 19.4.1 patch notes, versions 19.4.1, 19.3.3 and 19.2.7 were released on September 23, 2026, addressing CVE-2026-89078 and CVE-2026-93577, each with a CVSS score of 9.9. BleepingComputer reported on October 12 that GitLab warned of CVE-2026-97229, an integer overflow in its CI/CD Regular Expression Compiler; The Machine Herald covered that release when it appeared, noting that GitLab’s bug-fix lists carried Ruby regexp patch entries without saying how they related to the CVE. The Ruby post now states the connection.
GitLab’s 19.5.1 patch notes list CVE-2026-110264, rated CVSS 10.0, in a release dated October 21, 2026.
According to the Ruby post, GitLab addressed these issues in its own releases by patching the Ruby it ships.
Who Is Affected
Ruby says the 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}/. In its words, “Applications that only use regular expressions written by their own developers are not affected.”
The post also says that Regexp.timeout does not protect against these bugs, and that limiting pattern length does not reliably protect against them either, because some can be triggered by short patterns. Ruby recommends upgrading to 4.0.9, 3.4.12 or 3.3.13 or later, and, for those who cannot upgrade, avoiding compiling regular expressions from untrusted input.
Ruby 3.3 is in the security maintenance phase, in which the project normally releases only fixes for vulnerabilities. Ruby says 3.3.13 includes the fixes as an exception, because GitLab assigned CVEs to issues that rely on them.
No Ruby CVEs Yet
The Ruby post says: “We have not requested CVE identifiers in Ruby for these fixes, at least for now.” It explains that Ruby has generally considered it unsafe to compile and use a regular expression created from untrusted input, while noting that it has treated a double free in Regexp compilation as a vulnerability in earlier advisories. It adds that the Regexp documentation currently discusses untrusted patterns only in terms of denial of service and does not clearly say whether compiling an untrusted pattern is a supported use case.
The project says it plans to discuss how to document this, and whether to treat this kind of issue as a vulnerability in Ruby, including whether to request CVE identifiers. In the meantime it asks users to refer to GitLab’s CVE identifiers when tracking the issues, for example in a security scanner.
What We Don’t Know
The sources do not say whether the Ruby project will ultimately request its own CVE identifiers, or how the Regexp documentation will change. They also do not report any exploitation of the bugs outside GitLab’s disclosures.