What happened
GitLab is a platform where companies store source code, track work and run automated builds and deployments (CI/CD). Many organizations host it on their own servers. On October 12, 2026, GitLab released patch versions 19.4.2, 19.3.5 and 19.2.8, which among other things fix the critical flaw CVE-2026-97229. According to GitLab, under certain conditions it could have allowed an unauthenticated user to run arbitrary code on the server through a specially crafted regular expression in a CI/CD configuration.
The bug is in Onigmo, the regular expression library built into Ruby, the language GitLab runs on. GitLab fixed it by patching the Ruby inside its own packages and container images. Fixed versions of Ruby itself only came out on October 22 and 23, 2026, The Hacker News reports.
On October 28, 2026, the Alpine Linux project said an attacker had tried to exploit the flaw on its GitLab server. Alpine found no evidence that the attack worked but cannot rule it out, so it rebuilt the server from scratch and reset every account’s password. As of October 28, the flaw was not in the CISA KEV catalog, and the European EUVD database does not record confirmed exploitation either.
Why it is dangerous
This is an integer overflow (CWE-190). Think of an old car odometer: once it passes 999,999, it rolls back to zeros. A program whose counter “rolls over” like that suddenly miscalculates how much room it has for data. An attacker can use that to overwrite memory and run their own code. Here it happens while processing a regular expression, a search pattern for text, which GitLab reads from the CI/CD configuration.
GitLab says that under certain conditions the attack can be carried out over the internet by an unauthenticated user. Rapid7 built a working exploit in its lab and published proof-of-concept code on October 13, 2026. In its scenario, the attacker first has to write crafted files to a public project, and only the final request is unauthenticated. On servers where new users can register themselves and create projects, however, that hurdle effectively disappears.
In Rapid7’s test, the exploit ran commands as the git user that GitLab runs under. According to Alpine, a successful attack could expose user details, password hashes, 2FA secrets, CI/CD variables, runner tokens, integration credentials and private repositories.
- CVSS 10.0 (version 3.1) is the highest possible severity score on a scale of 0 to 10. It was assigned by GitLab itself.
- EPSS estimates the probability of exploitation in the next 30 days. As of October 29, 2026, it is 18.4%, higher than for 97.2% of scored vulnerabilities.
- CISA KEV is a list of flaws whose exploitation the US agency CISA has confirmed. This flaw was not on it as of October 28, 2026.
Who is affected
It affects self-managed GitLab Community Edition (CE) and Enterprise Edition (EE), in every installation type:
- 19.2 before 19.2.8
- 19.3 before 19.3.5, including 19.3.4, which GitLab originally listed as fixed
- 19.4 before 19.4.2
Installs compiled from source and custom container images that install Ruby separately are at particular risk. There, upgrading GitLab does not remove the flaw until Ruby is updated as well, as the Alpine Linux project found out.
GitLab.com and GitLab Dedicated are not affected because GitLab has already patched them. GitLab does not list the 19.5, 19.1, 19.0 and 18.11 branches as affected. Internet-facing servers with public projects or open registration are the most exposed.
How to check if you are affected
You can find the version in the GitLab Admin area (Dashboard overview) or on the /help page. On a server with the official package, these read-only commands help:
sudo gitlab-rake gitlab:env:infohead -n 1 /opt/gitlab/version-manifest.txtWith the official container, run the same inside the container (replace gitlab with your container name):
docker exec gitlab head -n 1 /opt/gitlab/version-manifest.txtFor source installs or custom images, also check the GitLab version and the Ruby used by the git user. Ruby 3.3.13, 3.4.12, 4.0.9 or later are fixed, Ruby 3.2 will not get a fix.
cd /home/git/gitlab && sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=productionsudo -u git -H ruby -vHow to fix it
Work in this order:
- Back up GitLab and its configuration following GitLab’s instructions.
- Upgrade installs from the official package or official container to the newest release on your branch. As of October 21, 2026, these are 19.4.3, 19.3.6 and 19.2.9, while 19.4.2, 19.3.5 and 19.2.8 already fix this flaw. The October 21 releases also fix a separate flaw, CVE-2026-110264.
- Move servers still on 19.3.4 to 19.3.6, because 19.3.4 is not fixed.
- For source installs or custom images, upgrade GitLab and also update Ruby to 3.3.13, 3.4.12, 4.0.9 or later. Ruby 3.2 reached end of life in April and will not get a fix.
- Users of the
alpinelinux/gitlabimage need to pull 19.3.6 again. - After upgrading, check the GitLab and Ruby versions again with the commands above.
If you cannot upgrade right away, Rapid7 suggests restricting anonymous access to public projects, stopping untrusted users from creating or writing to public projects, or blocking the CI lint route. Rapid7 notes that these steps only cover the attack route it tested and do not fix the flaw itself. Treat them as a stopgap until the upgrade is in place.
What if you may already be compromised
GitLab has published six Sigma detection rules for self-managed servers: 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. In your logs and monitoring, look especially for:
- repeated GitLab worker process crashes, 502 errors and failed CI jobs
- Ruby crash reports pointing to Onigmo
- unusually long file paths with non-ASCII characters and suspicious GraphQL ciLint requests
- newly registered accounts submitting CI configurations
Be aware: GitLab warns that a successful exploit may not cause a crash. According to Alpine, a successful exploit would leave no crash and no trace in the web logs. If your server ran a vulnerable version and was reachable from the internet, consider rotating passwords, runner tokens, CI/CD variables, access tokens and integration credentials. In that situation, Alpine rebuilt its server, reset passwords and replaced GitLab’s secret keys.
If you find any of these signs, or logs from the critical period are missing, bring in an incident response specialist. Back up your logs before making changes to the server.