GitLab CVE-2026-97229 in CISA KEV: Code Execution via a CI/CD Regex, Fixed in 19.2.8, 19.3.5 and 19.4.2

NVD published CVE-2026-97229 on October 13, 2026. CISA added it to the KEV catalog on October 29, with a deadline of November 1 — three days, the window CISA keeps for emergencies.

GitLab scored it at the ceiling: 10.0. A purpose-built regular expression in a CI/CD configuration can lead to arbitrary code execution on the GitLab server, and NVD's description says the attacker can be unauthenticated.

This is GitLab's second trip to the KEV catalog in two months, after CVE-2026-85706 in September, also rated 10.0.

The Vulnerability

NVD description (excerpt):

could have allowed an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration, due to insufficient regular expression validation.

How It Works

GitLab CI/CD accepts regular expressions in its configuration files — pipeline rules, branch and variable filters. Those expressions are compiled on the server. CVE-2026-97229 is an integer overflow in that path: the right expression makes an integer computation wrap around, and the wraparound opens the door to code execution.

CISA's KEV note adds something NVD doesn't: the issue lives in the Ruby/Onigmo regular expression compiler used by CI/CD, and other products may be affected by the same underlying bug. It points to a ruby-lang.org announcement dated October 23 covering regexp fixes tied to these GitLab CVEs. If you run Ruby applications that compile user-supplied regular expressions, read that announcement too.

Why 10.0

The vector stacks every aggravating factor:

• PR:N — no account needed, per the description;
• S:C — the impact reaches beyond the vulnerable component. Code running on a GitLab server touches source code, CI/CD secrets and deploy tokens;
• C:H/I:H/A:H — maximum impact on confidentiality, integrity and availability.

NVD says exploitation works "under certain conditions" without spelling them out. GitLab's advisory and the tracking issue in the references are where to check whether your setup qualifies. Until you have, assume it does.

What a Compromised GitLab Server Hands Over

A GitLab server is rarely just another box:

• the source code of every hosted project, and the ability to change it;
• CI/CD variables: cloud keys, registry credentials, deploy tokens;
• indirect reach into the runners, and through them into the environments they deploy to.

That's a foothold in the company's software supply chain, not just on one machine.

Affected Versions

Both Community (CE) and Enterprise (EE) editions carry the same bounds.

⚠️ These are bounds from NVD. GitLab ships patch releases often: install the latest release on your branch, not necessarily the one in the table. NVD's description only names branches 19.2 through 19.4; on anything older, the answer is moving to a supported branch, and GitLab's "patch release 19.4.2" advisory is the reference.

Check your version:

sudo gitlab-rake gitlab:env:info

or in the UI under Admin > Dashboard.

Detection

• .gitlab-ci.yml changes with unusually long or convoluted regular expressions, especially in public projects or forks
• Pipelines triggered by unknown accounts or from projects nobody owns
• Unexpected child processes spawned by GitLab's Ruby processes (Puma, Sidekiq)
• Outbound connections from the GitLab server to unfamiliar destinations
• CI/CD variables and access tokens read or changed without a matching ticket

The KEV entry points to the forensic triage requirements of BOD 26-04: patching alone isn't enough if the instance was exposed.

Mitigation

1. Upgrade

19.2.8, 19.3.5, 19.4.2 or later. The CISA deadline is November 1.

2. If the upgrade has to wait a few hours

• Take the instance off the internet or put it behind a VPN
• Disable open sign-up and review who can create projects and run pipelines
• Watch for CI/CD configuration changes

These only buy time. They reduce exposure; they fix nothing.

3. If the instance was exposed before patching

1. Rotate sensitive CI/CD variables, personal and deploy tokens, and runner registration keys
2. Review recent commits on protected branches
3. Check admin accounts and recently added SSH keys
4. Go through the application logs (/var/log/gitlab/) for the period between October 13 and the upgrade

Why Continuous Monitoring of Your GitLab Instance Matters

Sixteen days passed between publication and the KEV listing. A team following GitLab advisories saw it on October 13; a team waiting for its next patch cycle found out with three days to go.

With cveo.tech, record your exact GitLab version and get alerted as soon as a CVE affecting it is published or added to CISA KEV.