Ruby 4.0.9 Fixes Regex Bugs That Timeouts Cannot Stop

A crafted regular expression can corrupt memory while Ruby compiles it, and Regexp.timeout does not stop these bugs. The fixes landed in 4.0.9, 3.4.12 and 3.3.13, patching three Onigmo bugs behind four critical GitLab flaws. Here is how to identify exposed input paths, pick the right release, and avoid mitigations that do not work.

For a production Ruby service, the boundary is simple: does an attacker control the pattern being compiled? GitLab found that this compilation-time memory corruption could lead to code execution on its servers. Ruby says the exposure extends beyond GitLab to any application that compiles attacker-controlled patterns.

Which Ruby applications need these fixes?

Attacker control over the pattern is the deciding condition. Ruby says applications that use only regular expressions written by their developers are not affected. Merely using regular expressions is not enough to establish exposure.

The advisory identifies these ways an untrusted string can reach pattern compilation:

• An application passes the string to Regexp.new, Regexp.union or Regexp.compile.
• An application interpolates the string directly into a regular expression.

The interpolation form shown in the advisory is:

/#{input}/

This is an example of the code path to review, not a diagnostic payload. The question is where input comes from and whether an attacker can control it.

Trace the customer-supplied pattern to its compilation point. Distinguish a developer-written pattern from one assembled using text supplied by somebody outside the application.

How GitLab exposed the compilation problem

GitLab accepts user-supplied regular expressions, including patterns in CI/CD configuration. It found that crafted patterns could corrupt memory during compilation and addressed the resulting flaws by shipping patched Ruby builds.

The disclosures ran from September 23 through October 21. The two September 23 flaws each required a logged-in account and received severity scores of 9.9 out of 10.

The later flaws, CVE-2026-97229 on October 12 and CVE-2026-110264 on October 21, required no account and were each rated 10.0. CVE-2026-110264 reaches every GitLab version from 7.0 onward.

The useful distinction is where the failure occurs: the pattern can corrupt memory while being compiled. This is not a report about a matching operation taking too long. That distinction explains why a timeout is not the remediation here.

Choose and deploy a fully patched Ruby release

The fixed-release map below separates the supported branches and calls out the incomplete fix in 4.0.8.

Upgrade within your supported branch; move unsupported applications to 3.4 or 4.0. Ruby 3.2 reached end of life on April 1, 2026, a deadline that has already passed.

1. Identify the Ruby version used by each application under review and compare it with the fixed-release map.
2. Trace attacker-controlled strings to the compilation methods and interpolation form above. Use that review to establish which applications meet Ruby's exposure condition.
3. Upgrade exposed applications to the appropriate fixed release. For the 4.0 branch, select 4.0.9 rather than stopping at 4.0.8.
4. If an upgrade cannot happen yet, stop compiling regular expressions from untrusted input. This is the advisory's stated workaround.

The workaround changes the input the application accepts; it does not repair Onigmo. Treat it as an explicit decision about the pattern-supplying feature, rather than assuming an existing timeout setting covers the problem.

Install the GitLab release that carries the Ruby fix

Self-managed GitLab needs the release fixing CVE-2026-110264. GitLab shipped that repair on October 21 and backported it as far as 18.11.13.

The source lists these fixed GitLab releases:

• 19.5.1
• 19.4.3
• 19.3.6
• 19.2.9
• 19.1.9
• 19.0.10
• 18.11.13

GitLab bundles its own Ruby and patched that bundled copy. Installing one of these fixed GitLab versions applies the repair. For a self-managed instance, I'd make the GitLab release itself the remediation checkpoint, rather than assume that changing a separate Ruby installation addresses the bundled runtime.

GitLab also published detection rules for self-managed administrators to look for signs of exploitation attempts. These provide an investigation task alongside the upgrade, not an alternative to it.

GitLab.com already runs the patched version. GitLab says Dedicated tenants on recent internal releases need no action; that assurance is specifically scoped to those releases.

Ruby CVE matching and regex guardrails leave gaps

A Ruby inventory can fall through a CVE-matching gap even though fixes exist. Ruby has not requested its own CVE identifiers for these bugs and tells users to track GitLab's four identifiers instead.

The GitLab CVE records name only GitLab as the affected product. A scanner matching those records against installed Ruby versions therefore has nothing to match. I would not treat an empty Ruby finding list as the deciding evidence here; the installed release and the application's pattern inputs are the checks to make.

The advisory also rules out two seemingly relevant defenses:

• Setting Regexp.timeout does not stop these bugs.
• Capping pattern length is unreliable because short patterns can trigger the bugs.

Neither setting establishes that attacker-controlled compilation is safe. The supported choices remain a fixed Ruby release or, while an upgrade is blocked, stopping compilation of untrusted patterns. Ruby says it will update its advisory if it requests CVE identifiers of its own.

Prioritise the runtime accepting outside patterns

The clearest patching priority is an application that accepts attacker-controlled patterns, particularly a self-managed GitLab instance still missing the October 21 repair. Applications using only developer-written expressions fall outside the exposure condition Ruby describes.

Establish who controls the pattern, then check the actual Ruby or bundled GitLab release. Do not let an absent Ruby-specific CVE record override that review.

Patch the runtime or stop compiling untrusted patterns.