Upgraded GitLab and still vulnerable? The Ruby patch behind CVE-2026-97229

If you upgraded self-managed GitLab this month and assumed you were safe from CVE-2026-97229, it is worth a second look. Alpine Linux upgraded its own GitLab and was still attacked, because the real flaw is not in GitLab's application code: it is in the regular expression engine built into Ruby, and the GitLab upgrade alone did not replace it.

CVE-2026-97229 is rated CVSS 10.0. GitLab describes it as an integer overflow in its CI/CD regular-expression compiler, and it can be turned into remote code execution on the server. This guide explains who needs to act, how to tell in two minutes whether your install is really patched, and the order to fix it in.

Want it checked and patched without the downtime? Security patching →

What happened, and why an upgrade wasn't enough

The bug lives in Onigmo, the regular-expression engine Ruby uses. A crafted pattern triggers an integer overflow in the size of the compiled pattern, which corrupts memory. GitLab reaches that engine when it parses regular expressions in CI/CD configuration, so an attacker who can submit a .gitlab-ci.yml — for example through a newly registered account — can reach the flaw without any special privileges. Ruby's own Regexp.timeout does not protect against it, because the damage happens while the pattern is being compiled, not while it runs.

Alpine's write-up is the clearest account of why patching was confusing. GitLab shipped fixed releases on 12 October, but the fix is a set of patches to the Ruby that GitLab bundles. Alpine runs GitLab from a community image built against the standard system Ruby, so when it upgraded GitLab, the unpatched Ruby came along for the ride. On 20 and 21 October an attacker sent crafted CI configurations that crashed GitLab worker processes repeatedly while tuning the exploit against Alpine's exact build. Upstream Ruby only published the fixed versions on 23 October.

Are you affected?

• GitLab.com / Dedicated: no action. GitLab patched its managed fleet.
• Self-managed on official Omnibus packages or the official gitlab/gitlab-ee / gitlab-ce Docker images: upgrade GitLab to a fixed release and you get the patched bundled Ruby with it.
• Self-managed on a community or distribution image, a Helm chart with a custom base, or a source install that uses the system Ruby: this is the dangerous case. Upgrading GitLab is not enough; you must also update Ruby.
• Other Ruby services you run that compile untrusted regular expressions are a separate exposure — see below.

Check in two minutes

Print both versions that matter — GitLab, and the Ruby it actually runs. If either is below its fixed version, you are still exposed.

# Omnibus / official Docker image: prints the GitLab version AND the Ruby it runs
sudo gitlab-rake gitlab:env:info | grep -Ei 'gitlab version|ruby version'

# The exact Ruby binary GitLab uses on an Omnibus install
/opt/gitlab/embedded/bin/ruby -v

# Source or custom install: the system Ruby GitLab runs under
ruby -v

GitLab information
Version:        19.3.4          # below 19.3.5 / 19.4.2 -> GitLab itself is unpatched
Ruby Version:   3.3.9           # below 3.3.13 -> the regex engine is unpatched too

The fix, in order

1. 1
   Upgrade GitLab to a fixed release (19.4.2, 19.3.5, or the fixed patch level of your branch), following GitLab's version-by-version upgrade path. On official Omnibus or Docker builds this also replaces the bundled Ruby. See GitLab releases.
2. 2
   If GitLab runs on your system Ruby, update Ruby too to 3.3.13, 3.4.12 or 4.0.9 (or your distribution's patched package), then rebuild or reinstall the image. This is the step Alpine missed.
3. 3
   Restart every GitLab process (gitlab-ctl restart, or redeploy the containers). A running Puma or Sidekiq worker keeps the old Ruby in memory until it restarts.
4. 4
   Re-run the check above on the live server, and review your CI audit log and new-user signups around 20–26 October for crafted.gitlab-ci.yml submissions or repeated worker crashes.

Beyond GitLab: any Ruby app that compiles untrusted regexes

Ruby's advisory lists four GitLab-reported CVEs fixed together in 3.3.13, 3.4.12 and 4.0.9 (Ruby did not assign its own IDs). The bugs are in Onigmo itself, so any Ruby program that compiles a regular expression built from user input is potentially exposed — a search feature that accepts a pattern, a rules engine, a validation library that turns user input into a Regexp. If you run Rails or other Ruby services, update Ruby there as well, and avoid building regexes from untrusted strings.

Common questions

Want it checked and patched without the downtime?

I upgrade self-managed GitLab along its supported path, update the Ruby underneath it, restart cleanly and verify both versions on the live server. See security patching or bug fixing and debugging. This is one of several October 2026 critical fixes.

Sources

• Alpine Linux: GitLab security incident (CVE-2026-97229)
• Ruby: regexp fixes for the GitLab CVEs (3.3.13, 3.4.12, 4.0.9)
• GitLab releases