The Bug Was Never in GitLab. It Was in the Language.
Four critical GitLab flaws. Three bugs. One regex engine that never appeared on anybody’s software inventory. Ruby shipped the real fix on Friday, and it goes much further than GitLab’s.
What Happened?
Ruby released 4.0.9, 3.4.12 and 3.3.13 on 23 October. Between them, they closed three bugs in Onigmo, the regular expression engine built into the language: one double free and two integer overflows. Those three bugs sit underneath all four GitLab CVEs patched this month. GitLab had already shipped its own patched Ruby on 21 October. What changed on Friday is that everybody else can get the fix too. Ruby has not requested CVE IDs of its own, at least for now.
The 4.0 series got there in pieces
Two of the three fixes were already in, one as far back as 4.0.0 and one in 4.0.8. Then 4.0.9 arrived the very next day carrying the third. So if you upgraded to 4.0.8 this week and ticked the box, you are not finished.
What’s the Impact?
Two of the four score 10.0 and need no login. The other two score 9.9 and need one. CVE-2026-110264 reaches every GitLab release since 7.0, roughly 12 years of them. None of the four is in CISA KEV, and EPSS still sits under 1%.
The part your scanner will miss
Ruby has no CVE for any of this. So the component that actually carried the flaw has no identifier, no advisory entry, and nothing for a scanner to match on. Your inventory lists Ruby. Your scanner checks Ruby against a database holding nothing about these bugs. The only four identifiers that exist belong to GitLab, which leaves every Ruby app that isn’t GitLab outside the normal process entirely.
Who is actually exposed? Only applications that build a pattern from input an attacker controls, through Regexp.new, Regexp.compile, Regexp.union, or interpolation into a literal like /#{input}/. If your patterns were all written by your own developers, you are fine. And one detail worth repeating: Regexp.timeout does not help here. The damage happens while the pattern is being compiled, before any matching starts.
How to Avoid This
- Upgrade Ruby to 4.0.9, 3.4.12 or 3.3.13
- Running GitLab? Upgrade GitLab, not Ruby
- Audit every
Regexp.newfed by user input - Stop treating
Regexp.timeoutas a control - Retire Ruby 3.2, dead since 1 April 2026
Your Scanner Is Only As Good As Its Worst Blind Spot
The four GitLab CVEs will turn up in your reports. The Ruby bug sitting under them will not, because there is no identifier to report. That gap is the whole story.
- Surfaces all four GitLab CVEs once a connected scanner reports them on a host
- Puts KEV status and EPSS next to each one, so urgent separates from noisy
- Flags exploit evidence where it exists instead of ranking on CVSS alone
- Tracks which hosts are genuinely on the fixed GitLab versions, not just patched in theory
- For Ruby apps outside GitLab, the version check does the job the CVE feed cannot