CVE-2026-110264 reaches every GitLab version from 7.0 onward
GitLab disclosed four critical remote-code-execution vulnerabilities between September 23 and October 21 after finding that specially crafted regular-expression patterns could corrupt memory while Ruby compiled them. The most sweeping of those, CVE-2026-110264, affects every GitLab release from 7.0 onward, and two of the four reported flaws carry a 10.0 severity score and require no account to exploit.
Ruby releases: 4.0.9, 3.4.12 and 3.3.13 patch Onigmo regex engine bugs
Ruby shipped fixes in versions 4.0.9, 3.4.12 and 3.3.13 to address three bugs in Onigmo, the regular-expression engine embedded in the language. The 3.4.12 and 3.3.13 releases are the first in those series to include any of the three fixes. An earlier 4.0 release from the same week, 4.0.8, does not include the fix for CVE-2026-110264; Ruby advised 4.0 users to install 4.0.9.
Ruby also said it will not request its own CVE identifiers "at least for now" and instructed users to follow the four GitLab CVE numbers instead.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadHow the vulnerabilities work and which applications are affected
According to Ruby's advisory, the problem arises when an application compiles a regular expression from text an attacker controls. That occurs when a program passes an attacker-supplied string to Regexp.new, Regexp.union or Regexp.compile, or when it interpolates untrusted input into a literal pattern (for example, /#{{input}}/). Applications that only use regular expressions written by their own developers are not affected.
Ruby warned that the issue is not limited to GitLab: "any application that builds a regular expression from text an attacker controls is affected." The advisory makes two defensive points clear: setting Regexp.timeout does not prevent these bugs, and capping the length of a pattern is unreliable because short patterns can still trigger the flaws.
GitLab's timeline, severity and reporting
GitLab found the risky behavior in patterns that users can supply, such as CI/CD configuration patterns, and reported four distinct CVEs between September 23 and October 21. The first two, disclosed on September 23, required a logged-in account and were rated 9.9 out of 10. The October 12 CVE (CVE-2026-97229) and the October 21 CVE (CVE-2026-110264) require no account and were rated 10.0.
All four were reported through GitLab's bug bounty program by a researcher using the handle joaxcar. As of October 23, none of the four GitLab CVEs was listed in CISA's Known Exploited Vulnerabilities catalog.
What self-managed GitLab administrators should do
GitLab shipped a patched Ruby on October 21 and backported the fix for CVE-2026-110264 as far back as version 18.11.13. Administrators of self-managed instances were given specific package releases to install:
- 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 Ruby, and GitLab said Dedicated tenants on recent internal releases need no action because GitLab bundles and patched its own copy of Ruby. GitLab also published detection rules administrators can use to hunt for signs of exploitation attempts.
What this means for application developers and security teams
Developers and security teams should treat any code path that compiles a regular expression from untrusted input as potentially exploitable until the environment uses Ruby 4.0.9, 3.4.12, or 3.3.13. Ruby noted that versions 3.2 and earlier will not receive fixes: 3.2 reached end of life on April 1, 2026, with 3.2.11 as its final release, and Ruby recommended moving to 3.4 or 4.0. Where upgrades are not immediately feasible, Ruby's advisory advised stopping compilation of regular expressions from untrusted input.
Security teams should also account for a practical gap: because Ruby has not requested its own CVEs, tracking solely by CVE may miss vulnerable Ruby installations. GitLab's CVE records name GitLab as the affected product; a scanner that matches those CVE entries against installed Ruby versions will find no explicit link.
GitLab's disclosures and Ruby's patches close a dangerous vector — compiling attacker-controlled patterns — but leave administrators and developers with a short checklist: install the patched Ruby releases, avoid compiling untrusted patterns where possible, and apply GitLab's detection rules. Ruby said it will update its advisory if it requests CVE identifiers, a step that would help vulnerability scanners reconcile GitLab's CVEs with affected Ruby versions.
