What happened
On 23 October 2026, the Ruby project released Ruby 4.0.9, 3.4.12, and 3.3.13. The releases address several bugs in Ruby's Onigmo regular-expression engine. GitLab found that the underlying bugs could be used for remote code execution on GitLab servers, then published four CVE identifiers for the issues: CVE-2026-89078, CVE-2026-93577, CVE-2026-97229, and CVE-2026-110264.
The affected path is compilation of regular expressions supplied by users. GitLab compiles user-provided patterns, including patterns in CI configuration, with Regexp.new. According to Ruby's notice, specially crafted patterns could corrupt memory while Ruby compiled them; GitLab determined that this could be turned into remote code execution on its servers. GitLab patched the Ruby it ships in its own releases, while Ruby's releases carry fixes for the underlying engine bugs for other Ruby applications.
The fixes cover three root causes. CVE-2026-89078 concerns a double free when parsing a pattern fails after an alternation; the relevant Ruby change is #13332. It first appeared in Ruby 4.0.0 and is included in Ruby 3.4.12 and 3.3.13. CVE-2026-93577 and CVE-2026-97229 concern an integer overflow in the size of a compiled pattern, fixed by #19020; Ruby 4.0.8, 3.4.12, and 3.3.13 contain that fix. CVE-2026-110264 concerns overflow of internal IDs in a pattern with many repeats, fixed by #16801 and first included in Ruby 4.0.9. The three new releases listed in the announcement contain all of the fixes.
Ruby limits the affected population: an application must compile a string an attacker controls as a regular expression. The notice names Regexp.new, Regexp.union, and Regexp.compile, as well as interpolation into a regexp literal such as /#{input}/, as examples. Applications that use only regular expressions written by their developers are not affected. Regexp.timeout does not protect against these bugs, and limiting pattern length is also not reliable because some bugs can be triggered with short patterns.
Ruby recommends upgrading to 4.0.9, 3.4.12, or 3.3.13 or later. Where that is not immediately possible, its recommended fallback is to avoid compiling regular expressions from untrusted input. Ruby 3.3 is in security maintenance, where it normally receives only vulnerability fixes; the project says this release was an exception because GitLab assigned CVEs to issues that rely on the fixes. Ruby has not requested separate Ruby CVE identifiers at this point and plans to discuss both documentation and its vulnerability treatment for this class of issue.
What the archive adds
This is a new fact on a known GitLab patch story. The earlier Field Note, GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13, covered GitLab's patched installation versions. Ruby's notice extends the remediation path to Ruby applications that independently compile untrusted regular-expression strings.
Trend signal
No listed New Runtime pattern genuinely fits this language-runtime security release.
Connections to other events
The Ruby release is directly connected to the GitLab patch release above: GitLab assigned the four CVEs and patched the Ruby it ships, while Ruby has now published the underlying Onigmo fixes for supported Ruby series. The two releases address different deployment boundaries of the same reported flaws.
Why it matters
For teams building AI-assisted developer tools, automation services, CI integrations, or any application that turns external text into matching rules, the important distinction is between running a developer-authored regexp and compiling a user-controlled one. The latter is a security-sensitive operation even when the input is short and even when the application has configured Regexp.timeout.
The release also provides unusually specific operational guidance. Teams can inventory calls that construct regular expressions from requests, configuration, tenant settings, repository content, or other untrusted sources; then upgrade the relevant Ruby runtime rather than relying on a generic resource-limit control. GitLab's incident made the impact visible in one product, but the Ruby fixes are relevant wherever the same compilation APIs are exposed to hostile input.
Limits and uncertainty
The announcement does not establish that every application using dynamic regular expressions is exploitable. It says the bugs are reached only when an attacker controls the pattern string, and it does not provide exploit steps, affected deployment counts, or a general severity rating for independent Ruby applications. It also does not say whether Ruby will assign its own CVE identifiers later; it says the project is still discussing the documentation and vulnerability classification for compilation of untrusted patterns. This note therefore does not substitute for an application-specific security assessment.
Skill to build now
Perform a focused code search this week for Regexp.new, Regexp.union, Regexp.compile, and interpolated regexp literals. For every match, record whether any portion of the pattern can originate outside trusted developer-controlled code. Upgrade the process runtime to Ruby 4.0.9, 3.4.12, or 3.3.13 or later where that answer is yes. If an upgrade must wait, remove or redesign the path that compiles the untrusted pattern rather than treating a timeout or length cap as a complete control.
Reader takeaway
The actionable update is narrow but clear: upgrade Ruby if your application compiles regular-expression patterns controlled by an attacker. These fixes cover the Onigmo bugs behind four GitLab CVEs, and Ruby explicitly says that Regexp.timeout and pattern-length limits do not reliably remove the risk. Developer-authored static regexps are outside the affected case.
Open question
Will Ruby revise its regexp documentation and assign Ruby-specific CVE identifiers after deciding whether compilation of untrusted patterns is a supported use case?