GitLab’s CI/CD regex flaw is being exploited: upgrade GitLab and Ruby

What happened

On 12 October 2026 GitLab released 19.4.2, 19.3.5 and 19.2.8 for its self-managed Community and Enterprise Editions. The most serious fix, CVE-2026-97229, scored the maximum CVSS 10.0. GitLab’s advisory says that, under certain conditions, it “could have allowed an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration”.

On 29 October 2026 CISA added the bug to its Known Exploited Vulnerabilities (KEV) catalog, which means it has evidence of real attacks, and gave US federal agencies until 1 November to patch.

Affected versions are 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. GitLab’s own detection notes add an important detail: 19.4.1 contained an incomplete fix for an earlier, related bug (CVE-2026-93577), and CVE-2026-97229 bypasses it. If you installed the September security release (19.4.1, 19.3.3 or 19.2.7) and stopped there, you’re still exposed.

The root cause is Ruby’s regex engine

GitLab is a Ruby on Rails application, and the underlying bugs are in Onigmo, the regular expression engine built into Ruby. On 23 October 2026 the Ruby project released Ruby 4.0.9, 3.4.12 and 3.3.13 with fixes linked to four GitLab CVEs: CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264.

According to Ruby’s announcement:

• The bugs are only reached when an application compiles a regular expression from a string an attacker controls, for example with Regexp.new, Regexp.union, Regexp.compile or by interpolating input into a regex literal. Apps that only use patterns written by their developers aren’t affected.
• Regexp.timeout doesn’t protect against these bugs, and limiting pattern length doesn’t reliably help, because some can be triggered by short patterns.
• Ruby 3.3 is in its security maintenance phase, but 3.3.13 includes these fixes as an exception “because GitLab assigned CVEs to issues that rely on them”.

CISA’s catalog entry makes the same point: “Other products can potentially be affected by the same underlying Ruby/Onigmo Integer Overflow issue.” If you run Rails or other Ruby apps that let users type their own patterns (search filters, routing rules, validation rules), upgrade Ruby too.

Three more GitLab security releases since

Patching for CVE-2026-97229 alone isn’t enough any more. GitLab has shipped three further security releases:

Two points from the release notes are easy to miss:

• Bring-your-own Ruby or Git. GitLab’s official Linux packages and container images include the fixed Ruby and Git. If you compiled GitLab yourself or use your own Ruby runtime, GitLab says you “must also upgrade Ruby to 3.3.13, 3.4.12, 4.0.9 or later”. For Git, it says to rebuild Gitaly’s embedded Git and, if Git comes from your distribution, upgrade it to 2.56.1 or later (or a distribution-patched version).
• Old branches. The git bug affects every version from 16.2, but the 10 November fix was only released for 19.3, 19.4 and 19.5. Anything older needs to move to a current release.

How to check and upgrade

On a Linux package (Omnibus) installation, check your version with:

sudo gitlab-rake gitlab:env:info

Take a full backup first, as GitLab’s upgrade documentation advises, then install a specific version (Enterprise Edition shown; swap ee for ce on Community Edition):

# Debian / Ubuntu
sudo apt update && sudo apt install gitlab-ee=19.5.4-ee.0

# RHEL / AlmaLinux / Oracle Linux 9
sudo dnf install gitlab-ee-19.5.4-ee.0.el9

Expect downtime on a single-node instance if the jump includes database migrations (the 10 November release adds none). If you’re several versions behind, check GitLab’s upgrade path for any required stops before you jump.

For Ruby apps outside GitLab, ruby -v shows the version. Update Ruby through your version manager, base image or distribution, then redeploy and restart the app.

Look for signs of exploitation

GitLab published six detections for self-managed instances. They point to two request paths, the CI lint API (/api/v4/projects/:id/ci/lint) and the ciLint GraphQL mutation (/api/graphql), and to three places to look:

• Workhorse access log: a 502 with badgateway: failed to receive response: EOF on a POST to either path, often with a request body of roughly 2 MB. GitLab calls this the “authoritative crash-side detection”.
• GraphQL log (graphql_json.log): ciLint requests whose variables contain constructs such as {96000,}, \g<...> or \K.
• Puma error log: Ruby [BUG] crash reports with Onigmo frames such as onig_compile or compile_tree.

A quick first look on a Linux package install:

sudo grep 'ci/lint' /var/log/gitlab/gitlab-workhorse/current | grep '"status":502'
sudo grep -c '\[BUG\]' /var/log/gitlab/puma/puma_stderr.log

The full rules are linked from GitLab’s 19.4.2 release notes. If anything matches from before you patched, treat the server as compromised. A GitLab server holds CI/CD variables, deploy keys, runner tokens and access tokens, and all of them need rotating. Our guide to rotating leaked secrets walks through it.

Sources

• GitLab: Critical Patch Release 19.4.2, 19.3.5, 19.2.8 (12 October 2026) (opens in a new tab)
• GitLab: Critical Patch Release 19.5.1 and others (21 October 2026) (opens in a new tab)
• GitLab: Patch Release and Security Update 19.5.3 and others (29 October 2026) (opens in a new tab)
• GitLab: Critical Patch Release 19.5.4, 19.4.6, 19.3.8 (10 November 2026) (opens in a new tab)
• Ruby: Regexp compilation fixes related to GitLab’s CVEs (23 October 2026) (opens in a new tab)
• CISA: CISA Adds Two Known Exploited Vulnerabilities to Catalog (29 October 2026) (opens in a new tab)
• CISA KEV catalog entry: CVE-2026-97229 (opens in a new tab)
• GitLab security detections: CI lint Workhorse worker crash (opens in a new tab)
• GitLab docs: Upgrade a Linux package instance (opens in a new tab)