Ruby fixes regex-engine bugs behind critical GitLab code-execution flaws
Ruby released versions 4.0.9, 3.4.12 and 3.3.13 on October 23 to fix three bugs in Onigmo, the language's built-in regular-expression engine. The bugs are linked to four critical GitLab security flaws: a specially crafted pattern could corrupt memory while Ruby compiled it, potentially enabling code execution on affected servers. The practical impact extends beyond GitLab to any application that compiles a regular expression from text controlled by an attacker.
The affected programming pattern is specific. Ruby says an application is vulnerable when it passes attacker-controlled text to Regexp.new, Regexp.union or Regexp.compile, or inserts that text into a pattern through interpolation. Applications that use only regular expressions written by their own developers are not affected, according to the advisory. This distinction matters for businesses prioritising upgrades: the immediate review should focus on user-supplied patterns and other untrusted strings that reach regex compilation.
Ruby users should install 4.0.9 on the 4.0 branch, 3.4.12 on 3.4, or 3.3.13 on 3.3. Version 4.0.8 is not sufficient because it does not include the fix for CVE-2026-110264. Ruby 3.2 and earlier will not receive a fix; Ruby 3.2 reached end of life on April 1, 2026, so affected installations should move to a supported branch. If an upgrade cannot happen immediately, Ruby's advisory says to stop compiling regular expressions from untrusted input.
Two possible safeguards should not be treated as substitutes for an update. Setting Regexp.timeout does not stop these bugs, and limiting pattern length is unreliable because short patterns can also trigger them. That leaves patching, or temporarily removing the untrusted-input path, as the measures described in the supplied advisory.
GitLab administrators have a separate release requirement. Self-managed instances need the release that fixes CVE-2026-110264; GitLab shipped that fix on October 21 and backported it as far as version 18.11.13. GitLab.com already runs the patched version, while GitLab Dedicated tenants on recent internal releases need no action. Administrators of self-managed systems can also use GitLab's published detection rules to look for signs of exploitation attempts.
The incident creates a limitation for vulnerability-management teams. Ruby has not requested CVE identifiers of its own for these fixes, at least for now, while GitLab's records identify GitLab as the affected product. A scanner matching only CVE records against installed Ruby versions may therefore miss vulnerable applications outside GitLab. Teams should track the Ruby release guidance alongside GitLab's four CVE numbers rather than relying on an automated CVE match alone.