Ruby shipped emergency patches this week after three bugs in Onigmo, the language’s regular expression engine, were found to underlie four critical GitLab remote code execution (RCE) vulnerabilities. The issues let specially crafted patterns corrupt memory during regex compilation, and because GitLab compiles user-supplied patterns in some features, the result was severe: multiple high-severity CVEs, including unauthenticated 10.0-rated flaws. This post explains what happened, who’s at risk, and the practical steps administrators and developers should take right away.
What happened and why it matters
GitLab researchers discovered that when Ruby compiles certain regular-expression patterns supplied by users, the Onigmo engine could experience memory corruption. Memory corruption at compile time can be far more dangerous than a simple denial-of-service: in these cases it opened paths to remote code execution on affected GitLab instances. GitLab published four CVEs between late September and October that track the exploitation scenarios. Ruby responded by releasing patched versions (4.0.9, 3.4.12, 3.3.13) that contain fixes to the Onigmo engine.
How the bugs work, in practical terms
The vulnerabilities arise specifically during regex compilation — not when matching. If an application builds a Regexp from attacker-controlled text (for example, via Regexp.new, Regexp.union, Regexp.compile, or interpolation like /#{input}/), that compiled pattern can trigger unsafe behavior in Onigmo. Simple mitigations many teams might try—such as setting Regexp.timeout or capping pattern length—do not reliably prevent these problems: short patterns can still trigger memory corruption, and Regexp.timeout does not stop the underlying vulnerability during compilation.
Who is affected
Not all Ruby users are vulnerable. Applications that only use developer-authored, static regexps are safe from this class of bug. Systems that compile regexps from user input are at risk. GitLab is a clear example because it allows users to configure patterns (CI/CD regexes, user-supplied search or filtering patterns, etc.) that the server compiles. Any web app or service that exposes pattern-building to untrusted input should consider itself potentially vulnerable until patched.
GitLab’s timeline and scope
GitLab found and reported the issues through its bug bounty program. It published four CVEs across a month, two of which required authenticated access (rated 9.9) and two that required no account and were rated 10.0. GitLab.com and recent dedicated tenants are already running the patched Ruby build; self-managed administrators were advised to apply GitLab’s released updates, which GitLab backported across a range of maintained versions. Because GitLab bundles its own Ruby in many releases, installing GitLab’s patched packages is an appropriate remediation step for self-hosted GitLab.
Ruby releases and recommendations
Ruby issued fixes in releases 4.0.9, 3.4.12, and 3.3.13. Notably, 4.0.8 did not include one of the fixes (CVE-2026-110264), so users on 4.0 must upgrade to 4.0.9. Ruby 3.2 and earlier are end-of-life and will not receive these fixes; the Ruby project recommends upgrading to 3.4 or 4.0. If upgrading is impossible immediately, the only reliable interim mitigation is to stop compiling regular expressions from untrusted input — i.e., refuse or sanitize user-supplied pattern strings and switch to safer configuration approaches that avoid runtime Regexp construction.
Detection, monitoring and response
GitLab published detection rules administrators can use to search for exploitation attempts. Incident responders should:
- Review logs for regex compilation or unusual failures around user-supplied pattern processing.
- Apply relevant GitLab updates immediately for self-managed instances, using the versions GitLab provided in its advisories.
- If an instance handled user-supplied regex patterns and shows signs of compromise, conduct a full incident response: preserve forensic evidence, rotate credentials, and rebuild compromised hosts from trusted images where appropriate.
Why CVE tracking is imperfect here
Ruby has not requested CVE identifiers of its own for the Onigmo fixes and advised users to track the bug by GitLab’s CVEs. That creates a visibility gap: vulnerability scanners that map CVEs to vendor/product and then to installed Ruby versions may miss the risk because GitLab’s CVEs name GitLab as the affected product. Organizations that inventory Ruby installations should treat these GitLab CVEs as relevant to Ruby and to any app that compiles untrusted regexps, even if scanners don’t show a direct match.
Practical steps for developers and admins
- Patch: Upgrade Ruby to 4.0.9, 3.4.12, or 3.3.13 as applicable, or install patched GitLab packages for self-hosted GitLab.
- Avoid compiling untrusted regexps: Refactor features that accept pattern input from users so patterns are validated, sandboxed, or not compiled at runtime.
- Harden logging and monitoring: Add detection around pattern-compilation code paths and watch for memory-corruption symptoms or suspicious behaviors immediately after users submit patterns.
- Inventory and prioritize: Identify apps that construct regexps from input and prioritize them for code review and patching.
- Plan upgrades: Move off unsupported Ruby versions (3.2 and earlier) to maintained branches to receive future security fixes.
Closing thoughts
These Onigmo bugs underscore a persistent lesson: compiling or executing user-controlled code or patterns is hazardous. The immediate remedy is patching, but the longer-term fix is architectural — minimize runtime interpretation of untrusted input, apply least privilege around components that do compile or execute patterns, and keep runtimes current. For any team running user-facing features that accept regex-like input, assume risk until you’ve validated code paths and applied patches.
Licensed under CC BY-ND 4.0 International
