Ruby Patches the Regex Bugs Behind GitLab RCE Flaws

Ruby 4.0.9, 3.4.12 and 3.3.13 fix Onigmo regex bugs behind four critical GitLab RCE flaws. Who is affected and what to do now.

Ruby Patches the Regex Bugs Behind GitLab RCE Flaws
Photo: Artem Sapegin / Wikimedia Commons, CC0 (cropped)

If you run GitLab, you've probably patched this already. But the Ruby team just made it clear that the bug behind four of GitLab's scariest flaws this autumn isn't really a GitLab bug at all. It lives in Ruby itself, and any Ruby app that builds a regex from user input could be exposed.

What happened

On 23 October 2026 Ruby released versions 4.0.9, 3.4.12 and 3.3.13. In its advisory on ruby-lang.org, the team explains that the releases fix several bugs in Onigmo, the regular expression engine built into Ruby. GitLab had found that a carefully crafted pattern could corrupt memory while Ruby compiled it, and that this could be turned into remote code execution on GitLab servers.

GitLab had already patched its own bundled copy of Ruby and filed four CVEs between September and October: CVE-2026-89078 (a double free in the parser), plus CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264 (integer overflows in the compiler). The last one was fixed in GitLab 19.5.1 on 21 October. Ruby credits Johan Carlsson (joaxcar), who reported the issues through GitLab's bug bounty programme. I spotted it via The Hacker News on X.

Why it matters

The trigger is narrow but common enough to worry about. Your app is affected if it compiles a regular expression from a string an attacker controls, for example with Regexp.new, Regexp.union, Regexp.compile, or by dropping input straight into a literal like /#{input}/. Search boxes, filter rules and anything that lets users write their own patterns are the obvious places to look. If your code only uses patterns your own developers wrote, you're fine.

Two things make this trickier than usual. Ruby says Regexp.timeout won't protect you, and neither will capping pattern length, since some of the bugs fire on short patterns. And Ruby hasn't requested its own CVE numbers yet, so a vulnerability scanner that matches CVEs against your installed Ruby version may not flag anything. Ruby suggests tracking the issue by GitLab's four CVE IDs instead.

One more catch: Ruby 3.2 reached end of life earlier this year and won't get these fixes. If you're still on it, this is a good push to move.

What to do

  • Upgrade to Ruby 4.0.9, 3.4.12 or 3.3.13 (or your distro's patched build), then restart your app servers and background workers.
  • Search your codebase for Regexp.new, Regexp.union and interpolated regex literals that take request data, and treat those as the priority.
  • If you can't upgrade straight away, stop compiling patterns from untrusted input. Escape it with Regexp.escape when you only need a literal match.
  • Self-managed GitLab admins should be on a release that fixes CVE-2026-110264. GitLab.com is already patched.

This lands in the same week as PHP's run of code execution bugs, which I covered in PHP's latest RCE warning. If you self-host anything, it's worth keeping admin panels off the open internet; my Tailscale vs WireGuard guide covers the simple ways to do that.

Sources: Ruby advisory, Ruby 4.0.9 release notes, GitLab 19.5.1 patch release, with reporting from The Hacker News.