GitLab CVE-2026-97229: Exploited, in CISA KEV, and the Fix Lives in Ruby

Timeline (dates as published by each source)

GitLab version per install type

The rake task, API endpoint and chart mapping come from GitLab’s docs; the in-app Help > Help page also shows the version to signed-in users. On a Linux package the version answers the question, because the patched Ruby ships inside it. Swap in your own container name.

# Linux package: read 'GitLab information > Version'
sudo gitlab-rake gitlab:env:info

# Official Docker image: the same task inside the container
docker exec gitlab gitlab-rake gitlab:env:info

# Any install type, from your laptop (needs an access token)
curl --request GET \
  --header "PRIVATE-TOKEN: <your_access_token>" \
  --url "https://gitlab.example.com/api/v4/version"

# Helm chart: chart versions are not GitLab versions,
# map them on the chart version mappings page
helm list -n <namespace>

# Self-compiled: from /home/git/gitlab, as the git user
bundle exec rake gitlab:env:info RAILS_ENV=production

# fixed for CVE-2026-97229:  19.4.2, 19.3.5, 19.2.8
# fixed for both regex CVEs: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13

Whose Ruby is it? Containers, custom images and source installs

/opt/gitlab/embedded/bin/ruby is in the Linux package’s file list, and version-manifest.txt is where GitLab’s docs say the bundled versions are recorded. On a GitLab package, expect 3.3.10 to 3.3.12 even when fixed. Anywhere else, the Ruby number is the test.

# Linux package or official image: bundled Ruby, patched by GitLab
/opt/gitlab/embedded/bin/ruby -v        # 3.3.12 on 19.3 to 19.5, even when fixed
grep -iw ruby /opt/gitlab/version-manifest.txt

# Each running GitLab container: Linux-package image, or its own Ruby?
for c in $(docker ps --format '{{.Names}} {{.Image}}' | awk 'tolower($2) ~ /gitlab/ {print $1}'); do
  if docker exec "$c" test -x /opt/gitlab/embedded/bin/ruby; then
    echo "$c: Linux-package image, judge it by the GitLab version"
  else
    echo "$c: own Ruby: $(docker exec "$c" ruby -v 2>/dev/null || echo 'ruby not on PATH')"
  fi
done

# Self-compiled or custom image: this number must reach the fix in its series
ruby -v      # fixed: 3.3.13, 3.4.12, 4.0.9 · NOT fixed: 3.4.10, 3.4.11 · 3.2: no fix
apk info -v 2>/dev/null | grep '^ruby-[0-9]'     # Alpine: 3.3.13-r0 (3.21), 3.4.12-r0 (3.22+)
dpkg -l 'ruby3*' | awk '/^ii/ {print $2, $3}'    # Debian: ruby3.3 and ruby3.1 unfixed on 3 Nov

Close self-registration

Both options are in GitLab’s sign-up restrictions docs, including the Rails console line. Alpine’s attacker came in through a newly registered account.

# UI: Admin > Settings > General > New user account restrictions
#     clear 'Allow new user accounts' (or tick 'Require admin approval')

# Rails console on a Linux package install
sudo gitlab-rails console
::Gitlab::CurrentSettings.update!(signup_enabled: false)

Hunt with GitLab’s own log queries

These lines come from the detection rules GitLab linked in both advisories (gitlab-security-oss/tldr), with Linux package paths; on Helm, the same logs live on the Webservice and Sidekiq pods. GitLab calls a Workhorse 502 whose correlation ID never reached api_json.log ‘the single highest-confidence signal in the set’.

WH=/var/log/gitlab/gitlab-workhorse/current
APP=/var/log/gitlab/gitlab-rails/application_json.log
PUMA=/var/log/gitlab/puma/puma_stderr.log
SIDEKIQ=/var/log/gitlab/sidekiq/current

# 1. Workers that died on the lint or GraphQL routes (the detonation)
grep -E '"uri":"[^"]*(ci/lint|/api/graphql)' "$WH"* | grep -E '"status":502|badgateway'

# 2. Patterns the CI regexp guard caught (the probe, logged verbatim)
grep 'Gitlab::Ci::Build::Rules::Rule::Clause::RegexpMatcher' "$APP"* \
  | grep -E 'rejected at compile time|match timed out|time budget exceeded'

# 3. Native Ruby crashes through Onigmo (CI path and Org-mode path)
grep -B1 -A20 '\[BUG\]' "$PUMA"* \
  | grep -E 'org-ruby|headline\.rb|regexp_matcher\.rb|match_at|onig_search_gpos|onig_compile|compile_tree|compile_length_tree|rb_str_sub_bang'
grep 'A worker terminated, shutting down the cluster' "$SIDEKIQ"*

# 4. The trigger commit: paths near 255 bytes with a non-ASCII byte
#    (run it in a clone of each suspect project)
git ls-tree -r --name-only HEAD | awk 'length($0) >= 240' | grep -P '[^\x00-\x7F]'