Ruby has released versions 4.0.9, 3.4.12, and 3.3.13 to fix three bugs in Onigmo, the regular expression engine built into the language. The bugs lie behind four critical security flaws that GitLab patched over the past month.
GitLab found that a specially crafted pattern could corrupt memory while Ruby compiles it, potentially leading to code execution on its own servers.
Ruby says any application that builds a regular expression from text an attacker controls is affected, not just GitLab.
Which Applications Are Affected
In its advisory, Ruby said an application is affected only if it compiles a regular expression from a string an attacker controls. That happens when a program passes such a string to Regexp.new, Regexp.union or Regexp.compile, or places it inside a pattern through interpolation, as in /#{input}/.
Applications that only use regular expressions written by their own developers are not affected.
Ruby fixed the bugs in 4.0.9, 3.4.12, and 3.3.13. The 3.4.12 and 3.3.13 releases are the first in their series to carry any of the three fixes.
An earlier release from the same week, 4.0.8, does not include the fix for one of the flaws, CVE-2026-110264, so 4.0 users should install 4.0.9.
Ruby 3.2 and earlier will not get a fix. Ruby 3.2 reached end of life on April 1, 2026, and 3.2.11 was its final release. Ruby recommends moving to 3.4 or 4.0.
If you cannot upgrade yet, the advisory says to stop compiling regular expressions from untrusted input.
Two defenses that look like they would help do not. Setting Regexp.timeout does not stop these bugs. Capping the length of a pattern is also unreliable because short patterns can trigger bugs.
How the Bugs Reached GitLab
GitLab compiles regular expressions supplied by its users, such as the patterns in a CI/CD configuration. It found that crafted patterns could corrupt memory as Ruby compiled them, and it issued four CVEs between September 23 and October 21, fixing each by shipping a patched Ruby.
The first two, disclosed on September 23, each need a logged-in account and were rated 9.9 out of 10. The two from October, CVE-2026-97229 on the 12th and CVE-2026-110264 on the 21st, need no account and were rated 10.0, the maximum. 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. As of October 23, none of the four was listed in CISA’s Known Exploited Vulnerabilities catalog.
No Ruby CVE, for Now
Ruby has not requested CVE identifiers of its own for these fixes, “at least for now,” it said, and told users to track the issues by GitLab’s four CVE numbers instead.
That leaves a gap for anyone who scans by CVE. GitLab’s CVE records name only GitLab as the affected product, so a scanner that checks 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 it has long been unsafe to build a regular expression from untrusted input.
Its documentation still describes untrusted patterns only as a denial-of-service risk. Ruby said it will update its advisory if it requests any CVE identifiers.
For GitLab Administrators
Self-managed GitLab instances need the release that fixes CVE-2026-110264. GitLab shipped it on October 21 and backported it as far as version 18.11.13.
- 19.5.1
- 19.4.3
- 19.3.6
- 19.2.9
- 19.1.9
- 19.0.10
- 18.11.13
GitLab.com already runs the patched version, and GitLab Dedicated tenants on recent internal releases need no action, GitLab said. Because GitLab bundles its own copy of Ruby and patched it there, installing one of these fixed versions applies the fix.
GitLab also published detection rules that self-managed administrators can use to look for signs of exploitation attempts.
