GitLab Patches a CVSS 10.0 Unauthenticated Code-Execution Flaw in Its CI/CD Regex Engine

GitLab released patched versions 19.4.2, 19.3.5 and 19.2.8 for its Community Edition and Enterprise Edition on October 12, 2026, closing a maximum-severity vulnerability tracked as CVE-2026-97229. GitLab's own advisory rates the flaw at a CVSS score of 10.0, its highest possible severity, and describes it as allowing an unauthenticated user to execute arbitrary code on a self-managed GitLab server through a specially crafted regular expression placed in a project's CI/CD configuration.

The bug sits in GitLab's CI/CD regular expression compiler, the component that parses and evaluates regex patterns written into .gitlab-ci.yml pipeline files. According to GitLab's advisory, the root cause is an integer overflow triggered by "insufficient regular expression validation." A security researcher using the handle joaxcar reported the issue through GitLab's HackerOne bug bounty program.

Versions 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2 are affected, covering both CE and EE builds, per the same GitLab release notes. GitLab.com and GitLab Dedicated customers were already running the fixed code by the time the advisory went out; anyone operating a self-managed instance on an affected version needs to upgrade directly.

How a regex pattern turns into code execution

A technical write-up from the security vendor Rapid7 traces the overflow to how GitLab's Ruby-based regex engine, Onigmo, handles encoding changes. A pattern can pass initial validation while written in plain ASCII, but when GitLab later evaluates that same pattern against a repository path containing UTF-8 characters, Onigmo recompiles the regex for the new encoding. Rapid7 reports that this recompilation step is where the integer overflow occurs, producing invalid internal regex instructions that an attacker can use to hijack control flow and run their own code.

Rapid7 states it reproduced the exploit chain against GitLab 19.4.1 CE and confirmed it no longer worked once the instance was upgraded to the patched 19.4.2 release, and it published a proof-of-concept. Its write-up lists two preconditions for an attack: the ability to commit a crafted .gitlab-ci.yml file to a repository, and a repository path containing UTF-8 characters. Rapid7 notes that on instances allowing public self-registration and public project creation, both conditions are trivial for an outside attacker to satisfy, matching the advisory's own CVSS vector, which records that no authentication is required.

What else shipped in the same release

GitLab's October 12 patch release addressed 24 vulnerabilities in total, including CVE-2026-97229 and five other issues rated high severity, according to GitLab's own release notes. GitLab's advisory does not report any confirmed exploitation of CVE-2026-97229 in the wild as of publication. The Hacker News notes that a previous GitLab maximum-severity flaw, CVE-2026-85706, saw in-the-wild probing within hours of its disclosure last month, after proof-of-concept details became public.

For administrators who cannot patch immediately, Rapid7's advisory recommends restricting anonymous access to projects and disabling public project creation as a stopgap, while stressing that these settings only reduce exposure and do not fix the underlying compiler flaw itself.

Why this matters beyond security teams

GitLab's CI/CD pipelines are not only a corporate tool. Universities and research groups commonly run self-managed GitLab instances to host coursework repositories, automate the grading of programming assignments, and manage reproducibility pipelines for computational research, often with open project registration so students or outside collaborators can contribute. Those are exactly the conditions Rapid7 flags as removing the attacker's remaining preconditions, since a UTF-8 repository path is common in multilingual course or project names and a pipeline-triggering commit is the normal way students or contributors interact with such a repository.

Anyone running a self-managed GitLab instance for teaching, lab infrastructure or a research group's version control should check their installed version against GitLab's advisory and upgrade to 19.2.8, 19.3.5, 19.4.2 or later without waiting for a routine maintenance window. GitLab.com-hosted projects, including most free student and research accounts on the public service, required no action, per the same advisory.