Ruby Onigmo

Ruby just released versions 4.0.9, 3.4.12, and 3.3.13 to fix three specific bugs inside Onigmo, the regular expression engine built directly into the language, and these bugs are the root cause behind four critical security flaws that GitLab has been scrambling to patch over the past month.

GitLab discovered that a specially crafted pattern could corrupt memory while Ruby compiles it, potentially leading to remote code execution on its own servers, and while GitLab scrambled to ship patched Ruby versions, the underlying flaw affects any application that builds a regular expression from text an attacker controls.

Which Applications Are Actually Affected

This is not a blanket vulnerability, because Ruby’s advisory makes it clear that your application is only affected if it dynamically compiles a regular expression from a string that an attacker controls.

That specific scenario happens when a program passes an untrusted string to Regexp.new, Regexp.union, or Regexp.compile, or places it inside a pattern through interpolation, such as /#{input}/. If your application only uses regular expressions written by your own developers, you are completely safe from this specific attack vector.

The Fixed Releases and the EOL Trap

Ruby addressed these bugs across three specific releases, and it is crucial to note that the 3.4.12 and 3.3.13 versions are the first in their series to carry any of the three fixes.

If you are still running Ruby 3.2 or earlier, you are out of luck, because that branch reached end of life on April 1, 2026, and version 3.2.11 was its final release. Ruby strongly recommends moving to 3.4 or 4.0 to stay supported.

Why Standard Defenses Fail

If you cannot upgrade immediately, the advisory says to stop compiling regular expressions from untrusted input, but defenders need to know that two common defenses look like they would help but actually do not.

• Setting Regexp.timeout: This does not stop these specific bugs, because this is a memory corruption issue, not a catastrophic backtracking issue.
• Capping the pattern length: This is also unreliable, because short patterns can still trigger the underlying memory corruption.

How the Bugs Reached GitLab

GitLab compiles regular expressions supplied by its users, such as the patterns you put in a CI/CD configuration, and it found that crafted patterns could corrupt memory as Ruby compiled them.

GitLab issued four CVEs between September 23 and October 21, fixing each one by shipping a patched version of Ruby.

• September CVEs: Two flaws disclosed on September 23 each required a logged-in account and were rated 9.9 out of 10.
• October CVEs: Two flaws, CVE-2026-97229 and CVE-2026-110264, required no account at all and were rated 10.0, the absolute maximum.

The final flaw, CVE-2026-110264, reaches every GitLab version from 7.0 onward. A researcher using the handle joaxcar reported all four through GitLab's bug bounty program, and as of October 23, none of the four were listed in CISA's Known Exploited Vulnerabilities catalog.

The CVE Gap and Scanner Blindness

Here is the frustrating part for security teams: Ruby has not requested CVE identifiers of its own for these fixes, at least for now, and it told users to track the issues using GitLab's four CVE numbers instead.

That leaves a massive gap for anyone who scans by CVE, because GitLab's CVE records name only GitLab as the affected product, meaning a scanner checking those records against installed Ruby versions has nothing to match.

Ruby has treated this kind of bug as a vulnerability before, assigning CVE numbers to fixes in 2022 and 2024, even though its documentation still merely describes untrusted patterns as a denial-of-service risk.

For GitLab Administrators

Self-managed GitLab instances need the release that fixes CVE-2026-110264, which GitLab shipped on October 21 and backported as far as version 18.11.13.

You need to upgrade to one of the following versions: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, or 18.11.13.

Because GitLab bundles its own copy of Ruby and patched it there, installing one of these fixed versions applies the fix automatically. GitLab.com already runs the patched version, and GitLab Dedicated tenants on recent internal releases need no action.

FAQ

What is the Ruby Onigmo vulnerability?

It is a memory corruption bug in Ruby's built-in regular expression engine. If an application compiles a regex from an untrusted user input string, an attacker can trigger the bug, potentially leading to remote code execution.

Am I affected if I don't use GitLab?

Yes, if your web application takes user input and passes it directly into Regexp.new or uses string interpolation inside a pattern. If you only use hardcoded, developer-written regex, you are safe.

Why is there no CVE for Ruby itself?

Ruby decided not to request its own CVE identifiers and told users to track GitLab's CVE numbers instead. This creates a blind spot for automated scanners, because GitLab's CVE records only list GitLab as the vulnerable product.

Does Regexp.timeout fix this?

No. Regexp.timeout protects against ReDoS (catastrophic backtracking) attacks, but it does not protect against this type of memory corruption.

Which GitLab version fixes this?

Self-managed GitLab administrators need to upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, or 18.11.13.

Source: The Hacker News