CVE-2026-97229

What's affected. GitLab CE and EE, self-managed, versions 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. GitLab published the fix on October 12, 2026 and says GitLab.com and GitLab Dedicated are patched. Credit goes to joaxcar through GitLab's HackerOne bug bounty program.

The root cause is in Onigmo, the regular expression engine built into Ruby. GitLab compiles user-supplied patterns, such as those in CI configuration, with Regexp.new. Ruby's maintainers say crafted patterns can corrupt memory during compilation.

Source and custom-Ruby installs. GitLab applied its fix by patching the Ruby it ships. Ruby's own fix (an integer overflow in the size of a compiled pattern) is in Ruby 4.0.8, 3.4.12 and 3.3.13, and Ruby 4.0.9, 3.4.12 and 3.3.13 contain all four related Onigmo fixes. A GitLab built on an older stock Ruby stays exposed after the GitLab upgrade. Alpine Linux's post is the proof. It upgraded to GitLab 19.3.6 on October 22 and found on October 26 that the instance was still vulnerable, because its build used its own Ruby.

Related CVEs from the same root cause, per ruby-lang.org. CVE-2026-89078 and CVE-2026-93577 (fixed in GitLab 19.4.1) and CVE-2026-110264 (fixed in GitLab 19.5.1). Upgrading to the latest GitLab release on a fixed Ruby covers all four.

Who can exploit it. GitLab describes the flaw as exploitable by an unauthenticated user under certain conditions. The public proof of concept, and Rapid7's reproduction reported by Help Net Security on October 13, need an ordinary account that can push a branch to a public project for the setup step; the final request to the CI lint API (/api/v4/projects/:id/ci/lint) then needs no credentials. Alpine's attacker registered a new account the day before the attempt. Open sign-up plus public projects is the widest exposure.

Checks, in order. Run these only on GitLab instances your organization owns.

1. GitLab version. As an admin, open /help or the Admin area, or run sudo gitlab-rake gitlab:env:info on Omnibus (bundle exec rake gitlab:env:info RAILS_ENV=production on source installs). Anything in the affected ranges above is vulnerable.
2. How GitLab gets its Ruby. The gitlab:env:info output shows the Ruby version. On Omnibus and the official gitlab/gitlab-ce or gitlab/gitlab-ee images, Ruby lives under /opt/gitlab/embedded/bin/ruby, and the GitLab upgrade carries the fix. If the Ruby path GitLab uses points anywhere else (a source install, a distro package, a custom or community container image), run ruby -v and confirm 3.3.13, 3.4.12, 4.0.9 or later.
3. Internet exposure. Check whether the GitLab web interface and API (normally ports 443 and 80) are reachable from the internet or only from internal networks or a VPN.
4. Open sign-up. In Admin, Settings, General, Sign-up restrictions, see whether sign-up is enabled and whether new accounts need admin approval or a restricted email domain. Open sign-up means anyone can get an ordinary account.
5. Who can push CI configuration. List who can create projects and push branches that contain .gitlab-ci.yml, and which projects are public.
6. Runners are not the target. The code runs in the GitLab server process that compiles the regex, not on CI runners, so runner isolation does not reduce this risk. Still note which runners accept jobs from new or external users, since that matters for cleanup.

Upgrading GitLab, and Ruby where GitLab doesn't bundle it, is the fix. Use these to cover the gap, and test each one on the instance where it matters.

• Restrict sign-ups. Turn off open sign-up, or require admin approval and allowed email domains. Review accounts created recently.
• Limit project creation and push rights. Restrict who can create projects, and reduce public project visibility where it isn't needed, since the public proof of concept relies on a public project it can push to.
• Network restrictions. Put GitLab behind a VPN or an allowlist where possible. If you front it with a reverse proxy or WAF, consider limiting unauthenticated access to the CI lint API path, and test that legitimate pipelines still work.
• Use GitLab's detections. GitLab released six detections for self-managed customers with the patch: Onigmo native worker crash, GraphQL cilint hostile regexp, CI regexp oversized non-ASCII path, CI regexp guard rejection, CI lint Workhorse worker crash, and CI lint scripted client error burst.
• Verify what GitLab holds against records outside GitLab. Alpine checked its package sources and releases against external records before trusting the instance. If an attempt reached your server, do the same for source, tags and release artifacts, and rotate secrets.

• Repeated Puma or Sidekiq worker crashes, 502 errors and failed CI jobs clustered in time. Alpine saw eight worker crashes during its attack.
• Shells or unexpected child processes spawned by puma or sidekiq, and outbound connections from the GitLab host to unfamiliar addresses (the proof of concept returns command output through an HTTP callback).
• Bursts of requests to the CI lint API from new or anonymous clients, and memory spikes in web workers; the proof of concept generates more than 2 GiB of pattern code.
• New accounts created shortly before the anomalies, and downloads of your GitLab container image by unfamiliar accounts.

Is my GitLab safe if I already upgraded to 19.4.2?

If you run GitLab's official Omnibus packages or images, yes for this CVE, because they include the patched Ruby. If you built GitLab from source or run it in your own container image on stock Ruby, also check ruby -v and upgrade to 3.3.13, 3.4.12, 4.0.9 or later. Alpine Linux upgraded GitLab and stayed exposed for four days because of this.

Does an attacker need a GitLab account to exploit CVE-2026-97229?

GitLab describes it as exploitable by an unauthenticated user under certain conditions. The public proof of concept uses an ordinary account that can push to a public project for setup, then sends the final request without credentials. Open sign-up and public projects make that setup easy.

Is CVE-2026-97229 being exploited?

Alpine Linux reports an attempt against its GitLab on October 20 and 21, 2026, with no evidence of success. GitLab's advisory says nothing about exploitation, and as of October 29 the CVE is not on CISA's Known Exploited Vulnerabilities catalog. Check the catalog again before treating this as low priority.

Do my CI runners need patching?

No. The bug runs in the GitLab server when it compiles a regular expression from CI configuration. The server and the Ruby it uses are what need the fix.

Oct 29, 2026. First published. Alpine Linux's Oct 28 incident post is the exploitation source; not on CISA KEV.

• GitLab patch release 19.4.2 (CVE details, CVSS, credit, detections)
• Alpine Linux, GitLab security incident: attempted exploitation of CVE-2026-97229 (Oct 28, 2026)
• NIST NVD: CVE-2026-97229
• Ruby, Regexp fixes for GitLab CVEs and Ruby 3.3.13 release
• Help Net Security (Oct 13, 2026), Rapid7's reproduction and account requirements
• Public proof of concept, jburgess-r7 (read only, not run)
• CISA Known Exploited Vulnerabilities catalog (checked Oct 29, 2026)