Ruby and GitLab Security Flaws: CI/CD Risks
Published:

On October 23, 2026, the Ruby team released updates addressing the underlying bugs behind four security vulnerabilities reported by GitLab. Ruby 4.0.9, 3.4.12, and 3.3.13 fix problems in Onigmo, the regular expression engine used by Ruby. GitLab had found that these bugs could, under certain conditions, allow an attacker to execute code on a GitLab server.
GitLab had already addressed the issues in security releases published on September 23, October 12, and October 21, 2026. Ruby's announcement matters beyond GitLab because other Ruby applications may also compile regular expressions supplied by users.
Ruby's official announcement, October 23, 2026
What Caused the Vulnerabilities?
Regular expressions are patterns used to find or validate text. Developers use them in many everyday tasks, and GitLab also processes user-defined patterns in CI/CD configuration. Some of these patterns are compiled using Ruby's Regexp.new method.
The reported bugs occur while Ruby is compiling those patterns. Specially crafted input can cause memory-handling errors. GitLab identified ways in which these errors could be exploited to execute code on its servers.
GitLab published four security advisories. CVE-2026-89078 and CVE-2026-93577 describe scenarios involving an authenticated attacker. CVE-2026-97229 and CVE-2026-110264 describe scenarios that can, under certain conditions, be exploited without authentication. GitLab assigned CVSS 3.1 scores of 9.9 to the first two and 10.0 to the latter two.
These are GitLab's CVE identifiers. As of the October 23 announcement, Ruby had not requested separate CVE identifiers for the underlying bugs in Ruby itself.
Which Ruby and GitLab Systems Are Affected?
Not every Ruby application is exposed. According to Ruby's advisory, these bugs are reachable when an application compiles a regular expression from a string controlled by an attacker. Applications that use only fixed regular expressions written by their developers are not affected by these issues.
Ruby's Regexp.timeout setting does not address these bugs. It limits the time spent matching a regular expression, whereas the problems here can occur during compilation. Limiting pattern length is not a reliable fix either; some of the bugs can be triggered by short patterns.
For GitLab users, the important detail is the version of the GitLab server itself. Upgrading the Ruby version used by your own applications does not patch a vulnerable self-managed GitLab installation. GitLab's corresponding security update must be installed as well.
GitLab says that GitLab.com and GitLab Dedicated have been patched. Organizations running their own GitLab servers need to check and update those installations themselves.
How Do You Fix the Ruby and GitLab Vulnerabilities?
For Ruby applications, the project recommends Ruby 4.0.9, 3.4.12, or 3.3.13, or a later release containing the same fixes. Some fixes had already reached earlier Ruby 4.0 releases, but 4.0.9 is the first 4.0 release containing all the fixes associated with the four GitLab advisories.
Self-managed GitLab requires a patched GitLab release. GitLab's October 21 security announcement lists 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13 as releases containing the final related fix for their respective branches. Older or unsupported installations should be moved to a currently supported release. In general, administrators should install the latest security patch available for their supported GitLab branch.
Rather than manually replacing Ruby inside a packaged GitLab installation, administrators should use GitLab's own security updates. A backup and a tested upgrade plan can help avoid unnecessary downtime.
GitLab's October 21, 2026 security release
What Does a GitLab Vulnerability Mean for a Business?
GitLab may do far more than store source code. At many companies, it runs tests, prepares software packages, and manages deployments. Those tasks can require access to repositories, server connections, and deployment credentials.
What an attacker could access after successfully executing code on a GitLab server depends on that server's permissions. Broadly granted access can make the consequences more serious. Keeping GitLab patched matters, but so does limiting permissions and storing sensitive credentials appropriately.
The existence of a patch does not mean a particular company has been compromised. Organizations running affected versions should still update promptly and review their logs for unusual activity. GitLab has also published detection guidance for some of these vulnerabilities.
How Can Companies Protect Their Development Infrastructure?
Security advisories are hard to act on if no one knows which versions are running. Companies need an accurate record of their GitLab installations, Ruby applications, and important dependencies. When an advisory appears, that record helps identify what needs attention.
Ruby projects should also be reviewed for places where user input becomes a regular expression. Avoid compiling patterns directly from untrusted input where possible. Where user-defined patterns are a necessary feature, their risks should be assessed alongside the application's design and the supported Ruby versions.
Access permissions in CI/CD systems deserve regular review as well. A job that only runs tests should not have production deployment credentials unless it needs them. Changes should be tested before release, and logs should be monitored for unexpected errors or behavior. Patching is essential, but detecting problems early is part of maintaining secure systems too.
How Intellego Can Help Secure Your Development Infrastructure
Intellego Softworks develops custom software, maintains existing applications, and provides DevOps services. Our work includes setting up CI/CD pipelines, automated testing, controlled deployments, and application monitoring.
We can help you review the software and dependencies you rely on, identify which systems are affected by new security advisories, and plan the necessary updates. We can also help build a maintenance process that fits your development environment, including testing changes before they reach production.
If you want to review your GitLab installation, Ruby applications, or software delivery process, contact Intellego Softworks.
Questions and answers
- If GitLab is updated, do I need to update Ruby too?
- Use GitLab's security releases to update the Ruby components bundled with GitLab. If your organization also runs separate Ruby applications, check those independently. Updating GitLab does not update Ruby installations elsewhere.
- Does `Regexp.timeout` prevent these vulnerabilities?
- No. Ruby explicitly states that `Regexp.timeout` does not protect against these bugs because they can be triggered while compiling a regular expression.
- Is every GitLab installation at risk?
- No. Exposure depends on the installed GitLab version and the conditions required for exploitation. GitLab.com and GitLab Dedicated have already been patched. Organizations running self-managed GitLab should verify their versions.