Ruby Patches Three Onigmo Regex Bugs Behind Four Critical GitLab RCE Flaws

Ruby has shipped versions 4.0.9, 3.4.12 and 3.3.13 to close three memory-safety bugs in Onigmo, the regular expression engine built into the language. The same bugs are the root cause of four critical remote code execution vulnerabilities that GitLab patched between late September and late October 2026.

What happened

The flaws sit in the step where Ruby compiles a regular expression. A specially crafted pattern can corrupt memory during compilation, and in the right conditions that corruption can be turned into code execution on the server.

GitLab hit the problem first because it compiles patterns that its own users supply, for example regular expressions inside CI/CD configuration. It fixed the issue in its product four times, each time by bundling a patched copy of Ruby:

• Two CVEs disclosed on September 23 – both require an authenticated account and carry a CVSS score of 9.9.
• CVE-2026-97229 (October 12) and CVE-2026-110264 (October 21) – both are reachable without authentication and score the maximum 10.0. CVE-2026-110264 affects every GitLab release from 7.0 onward.

As of October 23, none of the four had been added to CISA's Known Exploited Vulnerabilities catalog, and we are not aware of confirmed in-the-wild exploitation.

Why it matters beyond GitLab

This is a Ruby problem, not just a GitLab one. Any Ruby application is exposed if it builds a regular expression from a string an attacker controls – for instance by passing user input to Regexp.new, Regexp.union or Regexp.compile, or by interpolating it into a pattern literal such as /#{input}/. Applications that only use regular expressions written by their own developers are not affected.

Two common-sense mitigations do not help here:

• Regexp.timeout limits how long matching runs, but these bugs trigger during compilation, before any timeout applies.
• Capping pattern length is unreliable, because short patterns are enough to trigger the bugs.

There is also a blind spot for defenders. Ruby has not requested its own CVE identifiers for these fixes, at least for now, and points users to the four GitLab CVEs instead. Those records list only GitLab as the affected product, so a scanner that matches CVE data against installed Ruby versions will find nothing to flag. Ruby's own documentation still treats untrusted patterns mainly as a denial-of-service risk, even though the project has issued CVEs for similar engine bugs in the past.

What to do

For Ruby applications:

• Upgrade: Ruby 4.0 → 4.0.9, Ruby 3.4 → 3.4.12, Ruby 3.3 → 3.3.13. Note that 4.0.8, released the same week, is missing one of the fixes, so go straight to 4.0.9. The 3.4.12 and 3.3.13 releases are the first in their branches to carry any of the three fixes.
• Ruby 3.2 and older will not be patched – 3.2 reached end of life on April 1, 2026. Plan a move to 3.4 or 4.0.
• Until you can upgrade, stop compiling regular expressions from untrusted input. Search your codebase for Regexp.new, Regexp.union, Regexp.compile and interpolated patterns fed by request data.
• Don't rely on CVE-based dependency alerts to tell you about this one – check your Ruby version directly, including the runtimes baked into container images.

For self-managed GitLab:

• Install a release that fixes CVE-2026-110264: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. Because GitLab ships its own Ruby, upgrading GitLab applies the fix.
• GitLab.com is already patched, and GitLab Dedicated tenants on recent internal releases need no action.
• Use the detection rules GitLab has published to review logs for signs of attempted exploitation, especially on instances exposed to the internet.

Bugs like this live in the gap between your code and the runtime underneath it, which is exactly where CVE feeds go quiet. Our AI-assisted code review traces where user-controlled data flows into dangerous sinks such as dynamic regex compilation, so this class of issue gets caught in your own code, not only after a vendor advisory names it.