Ruby patches regex engine bugs behind critical GitLab remote code execution flaws

Ruby has released versions 4.0.9, 3.4.12, and 3.3.13 to address three bugs in its built-in regular expression engine, Onigmo. These underlying defects were responsible for four critical remote code execution vulnerabilities recently patched in GitLab. The fixes are urgent for any developer maintaining Ruby applications that process user-supplied pattern strings.

What happened

The security issues originated in how Ruby compiles regular expressions from text controlled by an attacker. When a program passes such a string to methods like Regexp.new, Regexp.union, or Regexp.compile, or uses interpolation in a pattern like /#{input}/, the engine can corrupt memory during compilation. This memory corruption creates a path for arbitrary code execution on the server. While GitLab was the primary victim publicly identified, Ruby explicitly states that any application performing this operation is vulnerable.

GitLab discovered these flaws through its bug bounty program, with researcher joaxcar reporting all four instances. The company issued four Common Vulnerabilities and Exposures (CVE) identifiers between September 23 and October 21. The first two vulnerabilities, disclosed in late September, required a logged-in account and carried a severity rating of 9.9 out of 10. The subsequent two, CVE-2026-97229 and CVE-2026-110264, required no authentication and received the maximum severity score of 10.0. Notably, CVE-2026-110264 affects every GitLab version from 7.0 onward.

Ruby has not yet assigned its own CVE identifiers to these fixes, advising users to track the issue via GitLab’s records instead. This decision creates a visibility gap for security scanners that rely on matching CVEs to specific library versions, as GitLab’s records only list GitLab as the affected product. Ruby noted it has assigned CVEs for similar bugs in 2022 and 2024 but currently describes untrusted patterns in its documentation primarily as a denial-of-service risk rather than a code execution threat.

How it works

The vulnerability lies in Onigmo, the regular expression engine embedded within the Ruby language. When Ruby compiles a regular expression, it translates the pattern string into an internal structure used for matching. If an attacker supplies a specially crafted pattern, the compilation process can trigger memory corruption. This is not a problem of slow matching or resource exhaustion, which are typical concerns with complex regexes. Instead, the engine fails to handle certain pattern structures safely during the build phase, allowing an attacker to overwrite memory locations.

Common mitigation strategies often fail against this specific class of bug. Setting Regexp.timeout does not prevent the memory corruption because the error occurs during compilation, before matching begins. Similarly, capping the length of the input pattern is unreliable because short, carefully constructed patterns can still trigger the underlying engine defects. The only reliable defense is to avoid compiling regular expressions from untrusted input entirely or to upgrade to a patched version of the Ruby runtime.

Key details

• Ruby versions 4.0.9, 3.4.12, and 3.3.13 contain the necessary fixes for the three Onigmo engine bugs.
• Ruby 4.0.8 is insufficient as it lacks the fix for CVE-2026-110264; users must upgrade to 4.0.9.
• Ruby 3.2 and earlier versions will not receive fixes, as Ruby 3.2 reached end of life on April 1, 2026.
• Applications are only at risk if they compile regexes from attacker-controlled strings via Regexp.new, Regexp.union, Regexp.compile, or interpolation.
• GitLab fixed the issues in versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13.
• As of October 23, none of the four associated CVEs appeared in CISA's Known Exploited Vulnerabilities catalog.

Why it matters

For software engineers, this incident highlights a persistent danger in handling user input for dynamic pattern matching. Many developers assume that regex risks are limited to performance degradation or denial-of-service attacks. This event proves that memory safety issues in the compilation phase can lead to full remote code execution. It forces a re-evaluation of any feature that allows users to define search filters, validation rules, or configuration patterns using regular expressions.

The lack of dedicated Ruby CVEs also complicates automated security monitoring. Teams relying on standard vulnerability scanners may miss these patches if their tools only check for CVEs associated directly with the Ruby language package. Since GitLab bundles its own copy of Ruby, self-managed instances must update the GitLab application itself to receive the fix. This dependency chain means that infrastructure leads must track upstream language updates even when they appear as application-level patches in bundled services.

What you can do

• Upgrade Ruby to version 4.0.9, 3.4.12, or 3.3.13 immediately if your application compiles regexes from user input.
• Migrate away from Ruby 3.2 and earlier, as these versions will not receive security fixes for these bugs.
• Audit your codebase for uses of Regexp.new, Regexp.union, Regexp.compile, or pattern interpolation with untrusted data.
• Refactor features that allow user-defined regex patterns to use safer alternatives, such as predefined filter options or string matching.
• If you manage self-hosted GitLab instances, upgrade to one of the patched releases, such as 19.5.1 or 18.11.13.
• Implement detection rules provided by GitLab to monitor for signs of exploitation attempts on your servers.