Critical GitLab vulnerability CVE-2026-97229 is now being exploited
CISA added CVE-2026-97229, a GitLab vulnerability rated 10.0 out of 10, to its Known Exploited Vulnerabilities catalog on Thursday, October 29. The flaw lets an attacker who isn't logged in run code on a self-managed GitLab server, and at least one open-source project has already been targeted.
What the flaw does
CVE-2026-97229 is an integer overflow in the code GitLab uses to compile regular expressions in CI/CD configurations. GitLab says that under certain conditions, an unauthenticated user could run arbitrary code on the server by sending a specially crafted regular expression in a CI/CD configuration. GitLab rates it critical, with a CVSS score of 10.0.
It affects GitLab Community Edition and Enterprise Edition from 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. GitLab fixed it in those three versions on Monday, October 12. A researcher known as joaxcar reported it through GitLab's HackerOne bug bounty program.
GitLab.com already runs the patched code, and GitLab says every GitLab Dedicated customer was patched before the release went out. The risk is to companies and projects that host GitLab on their own servers.
CISA sets a Sunday deadline
CISA adds a flaw to the catalog when it has evidence attackers are using it. US federal civilian agencies have until Sunday, November 1, to fix it under CISA's directive BOD 26-04. CISA also flagged the flaw for forensic triage, so those agencies must look for signs of a break-in as well as patch.
CISA's entry also warns that the problem may reach beyond GitLab. The bug sits in Onigmo, the regular expression engine built into Ruby, and CISA notes that other products could be affected by the same underlying issue.
Alpine Linux was targeted
Alpine Linux said on October 28 that an attacker tried to exploit the flaw against its own GitLab server. A newly registered account began probing on October 20 and sent crafted CI configurations on October 21, crashing GitLab's worker processes 8 times. In 4 of those crashes, the attacker got partway through the exploit before it failed.
Alpine says it found no evidence the attack succeeded but can't rule it out. It rebuilt the server from scratch, reset every account password and replaced GitLab's secret keys. It says its package repository and October 21 releases were checked against outside records and were not tampered with.
Alpine's case also shows that upgrading GitLab may not be enough. GitLab's fix is a set of patches to Ruby that ships only in GitLab's official packages. Alpine's server ran standard Ruby, so upgrading GitLab alone didn't close the hole. The Ruby project released its own fix on Friday, October 23, in Ruby 3.3.13, 3.4.12 and 4.0.9.
What it means for you
This doesn't affect ordinary PCs and phones, and people who only use GitLab.com don't need to do anything. It matters to businesses, schools and open-source projects that run their own GitLab server.
If you run one, update now to a fixed release: 19.2.8, 19.3.5, 19.4.2 or later. GitLab's official packages already include the Ruby patch. If you installed GitLab from source or in a container that uses your own system's Ruby, also update Ruby to 3.3.13, 3.4.12, 4.0.9 or later. Patching doesn't undo a break-in that already happened, so also check the server for signs of compromise, the same step CISA requires of federal agencies.
If you have an account on Alpine's GitLab, the project asks you to set a new password and change it anywhere else you reused it. Developers of other Ruby apps should check whether their code builds regular expressions from text that users supply. The Ruby team says those apps are exposed and that its Regexp.timeout setting doesn't protect against these bugs.