On this page
CISA added GitLab CVE-2026-97229 to its Known Exploited Vulnerabilities catalog on 29 Oct, and the clearest public account of an attack against it is Alpine Linux's own GitLab server. An attacker with a fresh account spent 20 and 21 Oct sending crafted CI configurations at gitlab.alpinelinux.org. Alpine found no proof the code ran, could not rule it out, and rebuilt the server. The detail every self-managed admin should take from it: Alpine had upgraded to GitLab 19.3.6 on 22 Oct and was still exposed, because the fix lives in the Ruby that GitLab bundles, and Alpine's image used its own Ruby.
Short answer: CVE-2026-97229 is the CVSS 10.0 integer overflow in Ruby's Onigmo regex compiler that GitLab CI/CD configuration reaches. CISA lists it as exploited, with a 1 Nov 2026 due date for US federal agencies and forensic triage required. GitLab's Linux packages and official images are fixed from 19.4.2, 19.3.5 and 19.2.8. A GitLab built from source or in a container that installs its own Ruby also needs Ruby 3.3.13, 3.4.12 or 4.0.9. GitLab.com and Dedicated need no action.
We covered the patch itself on 12 Oct in the original CVE-2026-97229 write-up. This post is about what changed since: the KEV listing, the Alpine attempt, and the Ruby gap. The HOL Guard evidence pack for CVE-2026-97229 is the source record.
How to fix
Which fix you need depends on where your Ruby comes from.
Linux package (Omnibus), official GitLab Docker images, Helm chart: the patched Ruby ships inside the package. Install the newest patch on your branch. The 21 Oct releases (19.5.1, 19.4.3, 19.3.6, 19.2.9) carry this fix and also close CVE-2026-110264, a second Onigmo bug.
# Debian/Ubuntu (use gitlab-ce and -ce.0 for Community Edition)
sudo apt-get update
sudo apt-get install gitlab-ee=19.4.3-ee.0 # or 19.5.1-ee.0 / 19.3.6-ee.0 / 19.2.9-ee.0
# RHEL/Alma/Rocky
sudo dnf install gitlab-ee-19.4.3-ee.0.el9
# Docker
docker pull gitlab/gitlab-ee:19.4.3-ee.0
Source installs and any image that installs Ruby itself: upgrading GitLab is not enough. Upgrade GitLab, then move the Ruby that runs Puma and Sidekiq to 3.3.13, 3.4.12, 4.0.9 or later, and restart both. Ruby 3.2 is end of life and gets no fix, so a 3.2 install has to change Ruby series. If you run the community alpinelinux/gitlab image, pull alpinelinux/gitlab:19.3.6 again. Alpine says only the build published on 27 Oct has Ruby 3.3.13, and any 19.3.6 pulled before that is still vulnerable.
If you cannot upgrade today, Rapid7's suggestions cut off the one route it has demonstrated: block anonymous access to public projects, stop untrusted users from creating or writing to public projects, or block the CI lint API route at your proxy. Rapid7 is clear that this does not fix the compiler, and the route in the original private report may differ.
Check which Ruby your GitLab really runs
For Omnibus and official images, the GitLab version is the check. The fix is a patch GitLab applies to its embedded Ruby, so the Ruby version number alone will not tell you:
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
For source installs and custom images, ask the Ruby that runs the app, not the one on your PATH:
# source install
sudo -u git -H bash -c 'cd /home/git/gitlab && bundle exec ruby -v'
# custom container
docker exec <gitlab-container> ruby -v
Anything below 3.3.13 on the 3.3 series, below 3.4.12 on 3.4, below 4.0.9 on 4.0, or on 3.2 at all, is exposed no matter which GitLab version it serves.
What happened at Alpine
Alpine's incident report is unusually frank, and the timeline is the useful part:
- 13 Oct: Alpine upgraded to 19.3.4 instead of 19.3.5, which it calls a mistake. GitLab first named 19.3.4 as fixed and later corrected that to 19.3.5.
- 20 and 21 Oct: a newly registered account sent crafted CI configurations. GitLab workers crashed 8 times. In 4 of those crashes the attacker got partway through the exploit before failing. On 21 Oct users saw 502 errors and failed CI jobs. The attacker also pulled Alpine's GitLab container image, which Alpine reads as tuning the exploit to its exact build.
- 22 Oct: Alpine upgraded to 19.3.6. That did not fix it, because its image used standard Ruby.
- 23 Oct: the account was blocked. Ruby released the upstream fix the same day.
- 25 and 26 Oct: the attacker came back and failed to get in. On 26 Oct Alpine found the server was still vulnerable.
- 27 and 28 Oct: GitLab closed to everyone but developers and build servers, rebuilt, all passwords reset and GitLab's secret keys replaced.
Alpine checked that its aports repository, the packages built 20 to 24 Oct and the 21 Oct releases came from commits it verified against records outside GitLab, and it says package signing keys were never on that server. What it could not do was prove the negative. In its words, a successful exploit "would leave no crash and no trace in the web logs," background job logs from the attack day were gone, and nobody logged outbound connections.
The KEV entry does not say what evidence CISA used. Its notes point to Ruby's advisory and warn that other products using the same Onigmo code may be affected.
What CISA's forensic triage flag means for you
This entry carries forensicTriage: Yes, so a patch alone does not close it for federal agencies. For everyone else the Alpine report is the reason to look before you restart: a worker crash is the only loud signal, and a working exploit may not produce one. Places to start on an Omnibus server:
# anonymous CI lint calls that name a ref (the trigger in Rapid7's chain)
sudo grep '/ci/lint' /var/log/gitlab/gitlab-rails/api_json.log | grep content_ref
# Ruby crash reports from Puma workers
sudo grep -nF '[BUG]' /var/log/gitlab/puma/puma_stderr.log*
# things the git user should not own or run
sudo find /tmp /var/tmp -user git -newermt 2026-10-12 -ls
sudo crontab -l -u git; sudo ls -la ~git/.ssh/
GitLab's 19.4.2 release notes list six detection rules for self-managed customers, including an Onigmo native worker crash, a hostile regexp in GraphQL ciLint, and a CI lint worker crash. Look for unexpected child processes of Puma or Sidekiq and new outbound connections from the GitLab host. If anything points to code execution, treat the server as compromised and rotate what Alpine listed as at risk: gitlab-secrets.json, CI/CD variables, runner tokens, personal and project access tokens, and webhook and mirror credentials.
Who is not in scope
- GitLab.com and GitLab Dedicated. GitLab patched both before disclosure.
- Omnibus and official-image installs already on 19.4.2, 19.3.5, 19.2.8 or later. The patched Ruby came with the package. 19.3.4 is not fixed.
- GitLab 19.1 and earlier, for this CVE. GitLab's affected range starts at 19.2. Those branches still need the 21 Oct releases for other bugs.
- Ruby apps that never compile a regex from user input. Ruby says the bug is reached only through
Regexp.new,Regexp.union,Regexp.compileor interpolation of attacker text.Regexp.timeoutdoes not help if you do.
What this is not
It is not a confirmed breach of Alpine: the project found no sign that code ran and says its packages and releases were not tampered with. It is also not a one-request worm in the route anyone has shown publicly. Rapid7's working exploit needs write access to a public project first, which an open sign-up page gives away, and only the final CI lint call is anonymous.
What do people ask about CVE-2026-97229 on CISA KEV?
When was CVE-2026-97229 added to CISA KEV?
On 29 October 2026, in catalog version 2026.10.29. The due date for US federal civilian agencies is 1 November 2026, forensic triage is required, and ransomware use is listed as unknown.
Does upgrading GitLab fix CVE-2026-97229?
For the Linux package and official GitLab images, yes, from 19.4.2, 19.3.5 or 19.2.8. For source installs and images that bring their own Ruby, you also need Ruby 3.3.13, 3.4.12, 4.0.9 or later.
Was Alpine Linux hacked through CVE-2026-97229?
Alpine says an attacker tried on 20 and 21 October and came close. It found no evidence of code execution but could not rule it out, so it rebuilt its GitLab server and reset all passwords. It verified its packages and releases were not modified.
Which Ruby versions fix the Onigmo bug behind CVE-2026-97229?
Ruby 3.3.13, 3.4.12 and 4.0.9, released 23 October 2026. Ruby 3.2 receives no fix.
Related coverage
References
- CISA Known Exploited Vulnerabilities catalog (version 2026.10.29)
- Alpine Linux: GitLab security incident, attempted exploitation of CVE-2026-97229
- Ruby: Regexp compilation fixes related to GitLab's CVEs
- GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
- GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9
- Rapid7: CVE-2026-97229 analysis and mitigations
- The Hacker News: Attacker Tried to Exploit Alpine Linux's GitLab via CVSS 10.0 Flaw Its Ruby Left Open
