GitLab CVE-2026-97229: a CVSS 10.0 with a public-project asterisk
On Oct 12, GitLab shipped an emergency patch for CVE-2026-97229, an integer overflow in the CI/CD regular expression compiler that lets a remote attacker run arbitrary OS commands on the server. GitLab scored it CVSS 10.0, the maximum. Self-managed instances on the 19.2 through 19.4 lines need 19.2.8, 19.3.5, or 19.4.2. GitLab.com is already patched, and Dedicated customers need no action.
What changed
- The flaw (CWE-190) sits in the compiler that parses, compiles, and evaluates regular expressions in pipeline configuration files.
- The mechanism, per Rapid7's Oct 13 writeup: a crafted regex compiles in a compact US-ASCII representation and passes GitLab's validation. When it is later evaluated against a specially formed UTF-8 repository path, Ruby's Onigmo regex engine recompiles it for the new encoding. An integer overflow in the compiler's program-size calculation then generates invalid regex instructions, and the resulting loss of control-flow integrity runs attacker-controlled Onigmo VM operations, ending in an OS command as the GitLab git user.
- Rapid7 reproduced the full chain against the official GitLab 19.4.1 CE image and confirmed the same input does not execute against patched 19.4.2. A proof of concept was published on Oct 13.
- GitLab credited researcher "joaxcar," who reported the flaw through GitLab's HackerOne program (per GitLab's advisory).
- Fixed versions are 19.2.8, 19.3.5, and 19.4.2. One correction worth noting: early coverage listed 19.3.4, but GitLab's release documentation superseded it with 19.3.5 because of an additional issue, so 19.3.5 is the one to target.
- As of Oct 13: no confirmed exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities catalog. A Censys scan found roughly 25,766 hosts running affected versions.
Why it matters
- The "unauthenticated" label needs a footnote. CVSS rates the trigger as needing no login, but Rapid7 found the attacker must first get a malicious
.gitlab-ci.ymlplus a UTF-8 repository path committed to a branch of a public project. On an instance where users can self-register and create public projects, that precondition is trivially satisfied. On a locked-down instance, it is not. The useful question is which kind of instance you run. - A compromised GitLab server is a bad asset to lose: source code, the ability to inject into build pipelines, and stored API keys and database credentials.
- This is the third regex-compiler flaw in GitLab in roughly a month, after two CVSS 9.9 regex bugs patched on Sep 23 (per a DEV Community analysis). Attackers now know exactly which component to keep probing.
The catch
- The interim mitigations only narrow the delivery path. Restricting anonymous access to public projects and keeping untrusted users from creating or writing to them reduces exposure, but Rapid7 is explicit that these controls do not fix the compiler. Patching is the remediation, and the recommendation is to upgrade outside the normal patch cycle.
- A 10.0 measures how exploitable the bug is and how bad the impact is, not how many of your servers are exposed or whether anyone is actively using it. No KEV listing yet.
- The first move in any environment is inventory: is there a self-managed GitLab anywhere, and which minor line is it on? The 19.3.4 to 19.3.5 correction is the reason to check the vendor's current release list instead of an earlier advisory when writing the scanner rule.