Patched GitLab, still exposed: the CI regex bug CISA lists as exploited, and the Ruby step people miss

GitLab fixed a critical flaw in how it reads CI pipeline files on October 12, and CISA now lists it as exploited. Anyone running their own GitLab server should be on 19.4.2, 19.3.5 or 19.2.8 at the very least, and really on the October 29 builds, because three related bugs sit next to this one. If you built GitLab yourself or run it in your own container image, the upgrade alone can leave you exposed. Read the section on Ruby before you close the ticket.

A self-managed GitLab server is rarely just a code store. It holds the CI/CD variablesdefinitionValues GitLab stores and passes to pipeline jobs, often passwords, tokens and cloud keys. Whoever controls the server can read them. your pipelines read, which often means cloud access keys, deploy tokens and database passwords. It knows every runner and can hand jobs to them. Whoever controls that server can usually reach production through the same doors your deploy jobs use.

CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 29 and marked it for forensic triage. That second flag matters for anyone doing incident response: CISA expects affected agencies to look for signs of compromise, and patching alone doesn't settle the question. Its note also warns that other products could be hit by the same underlying Ruby bug.

We do have one public account of an attack. Alpine Linux, the Linux distribution, wrote up an attempt against its own GitLab on October 20 and 21, about a week after the fix came out. A newly registered account sent crafted CI configurations, crashed GitLab's worker processes eight times and got partway through the exploit in four of them. Alpine found no evidence that code ran, couldn't rule it out, and rebuilt the whole instance from scratch.

For engineers: the weakness is CWE-190, an integer overflow. Ruby calls it an overflow in the size of a compiled pattern, and GitLab's detection notes add that a program over INT_MAX wraps a signed 32-bit jump offset negative, so at match time the regex VM jumps out of its compiled buffer into heap memory the attacker has shaped. Ruby's notice says the bugs are reached only when an application compiles a regular expression from a string an attacker controls, through Regexp.new, Regexp.union, Regexp.compile or interpolation such as /#{input}/. GitLab does exactly that with patterns in CI configuration. Ruby also says Regexp.timeout doesn't help here, and neither does capping pattern length, since some of these bugs fire on short patterns.

This is the third patch in a row for the same family of bugs, and the order matters. In September GitLab fixed two regex bugs that needed a logged-in user. The fix for one of them in 19.4.1 turned out to be incomplete, and CVE-2026-97229 is the way around it, with no login needed. Then on October 21 GitLab fixed a fourth bug, CVE-2026-110264, which also needs no login and reaches back to GitLab 7.0.

Read the 'not affected' cells with care. They refer to CVE-2026-97229 only. CVE-2026-110264 reaches every line back to 7.0, so an 18.11 server that skipped October is still open to a no-login bug rated 10.0.

Here's the trap. GitLab's fix lives in the copy of Ruby it bundles in its Linux package and official container images. Its release notes list the change as a Ruby regexp patch for Ruby 3.3 and 3.4, applied to the omnibus-gitlab and cloud-native image builds. If your GitLab runs on a Ruby you installed yourself, the new GitLab code arrives without the fix.

Alpine found this out the hard way. It upgraded to GitLab 19.3.6 on October 22, and its post says that didn't fix the vulnerability, because its image ran standard Ruby. Someone noticed the server was still vulnerable on October 26, and Alpine rebuilt it on 19.3.7 with a fixed Ruby. Earlier, on October 13, it had moved to 19.3.4 by mistake when 19.3.5 was the one with the fix. Anyone can make either slip in a busy week.

If you're short on time, check the version first and the Ruby second. A Linux package install reports one version, and that's the one that counts. A self-built server needs both answers, because the GitLab version tells you nothing about the Ruby underneath it.

# example output, values made up. First a Linux package server, then a self-built image
sudo gitlab-rake gitlab:env:info  # Linux package
Ruby Version: 3.3.x   Version: 19.3.4-ee
# 19.3.4 is older than 19.3.5, so this box is still open. Go to 19.3.7
docker exec gitlab ruby -v   # on your own image, this number decides it
ruby 3.3.12
# GitLab may say 19.3.6, but this Ruby has no fix. Rebuild on 3.3.13 or later
sudo grep -c 'ciLint' /var/log/gitlab/gitlab-rails/graphql_json.log   # a big jump in lint calls from one user is worth reading
sudo grep -l 'onig_compile' /var/log/gitlab/puma/puma_stderr.log*   # crashes inside Ruby's regex compiler
/var/log/gitlab/puma/puma_stderr.log.1
# A native crash through Onigmo is worth a closer look. Pull the full report before logs rotate

GitLab's detection notes explain what each log can and can't show. The GraphQL log records the CI lint request's variables in full, so a hostile pattern sent as a variable shows up there as written, provided the request finished. The REST API log filters the CI content, so all you get is a burst of server errors on the lint endpoint from a scripted client. GitLab says its GraphQL rule catches probes rather than the detonation, and its Workhorse crash rule warns that a successful exploit can leave no 502 error at all.

GitLab has now fixed regex bugs in three releases since September. It compiles patterns that users write, and Ruby's notice says Ruby has generally considered compiling untrusted patterns unsafe. Expect more of these. Set the server up so the next one costs you a short patch window instead of a rebuild.

The biggest single change is getting long-lived secrets out of CI/CD variables. GitLab jobs can request an ID token with the id_tokens keyword and trade it for a short-lived secret, and GitLab documents a secrets:vault keyword that does this with HashiCorp Vault. A stolen server then gives an attacker much less to take, and what it does give expires. Our HashiCorp Vault page and Terraform page cover how that fits a Terraform pipeline.

Code repositories add one more check. If an attacker owned the server, they could have changed code or tags. Alpine checked commits from October 20 to 22 against records outside GitLab, a developer's clone and its build servers, and is extending that check to October 27, when it closed GitLab. If your developers' local clones and your build logs reach back far enough, you can do the same check.

All three are made up, and none is a real incident or a Cohash client. The versions and behaviour in them come from GitLab's, Ruby's and Alpine's own pages.

The upgrade is usually the easy part. The slow work comes after it, when someone has to find which pipelines hold real keys and move them out of GitLab. Our DevSecOps practice works on CI hardening and image rebuilds, and our Terraform and Vault engineers set up the ID token and Vault pattern described above. If you'd like a second look at your exposure, start with an assessment.