GitLab has shipped fixes for a maximum-severity integer overflow in its CI/CD Regular Expression Compiler that allowed unauthenticated attackers to run arbitrary code on self-managed servers using a crafted regular expression in pipeline configuration. The flaw, tracked as CVE-2026-97229, was reported through GitLab's HackerOne bug bounty program by a researcher using the handle joaxcar and was disclosed in a Monday advisory alongside patched releases for the Community and Enterprise editions. GitLab.com already runs the fixed code, and GitLab Dedicated customers are unaffected.

What went wrong in the regex compiler

The affected component parses, compiles, and evaluates regular expressions that appear in a project's pipeline configuration files. According to GitLab, insufficient validation of those expressions let an unauthenticated user trigger an integer overflow and, under certain conditions, achieve code execution on the GitLab server.

The key detail for defenders is that no account or API token was required — the attack path begins with content that reaches the regex compiler from a CI/CD configuration. GitLab characterized the underlying weakness as an integer overflow issue in the CI/CD Regular Expression Compiler.

Fixed versions

GitLab patched both CE and EE. Installations on the following branches need to move to the listed release or later:

The vendor's guidance is blunt: these releases carry important bug and security fixes, and every self-managed instance should be upgraded immediately. The full patch notes, including the CVE-2026-97229 entry, are in the GitLab 19.4.2 patch release announcement.

Hosted deployments need no action. GitLab.com is already on the patched version, and GitLab Dedicated customers are explicitly excluded from the remediation requirement.

Checking exposure and upgrading

For self-managed Omnibus installations, confirm the running version before and after maintenance:

cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
sudo gitlab-ctl status

If the reported version falls anywhere in the affected ranges, upgrade to 19.2.8, 19.3.4, or 19.4.2 (or newer) and then re-check the VERSION file and service health:

sudo gitlab-ctl reconfigure
sudo gitlab-ctl status

Because the vulnerable surface is CI/CD configuration rather than an authenticated API, inventory any GitLab instance that accepts pipeline definitions from users you do not fully trust, and prioritize those systems. Restricting who may merge changes to .gitlab-ci.yml and requiring review for pipeline configuration edits are reasonable defense-in-depth controls, though they are not a substitute for patching.

Technical background

Regular expression compilers translate a pattern into an internal program or automaton before matching. Bounded repetition syntax such as {n,m}, nested groups, and counted subexpressions force the compiler to compute buffer and state sizes from values supplied by the pattern author. If those multiplications or additions are performed in a fixed-width integer without bounds checks, the computed size can wrap around to a small value. The compiler then allocates a buffer that is far too small and writes the expanded program into it, producing a heap or stack overflow that an attacker can shape into control-flow hijacking.

This is a well-known failure mode in regex engines and parsers generally, not something unique to this CVE. The defensive lesson is that any component accepting attacker-influenced patterns must validate size arithmetic before allocation and cap pattern complexity. Where such a component is reachable without authentication, the resulting bug is typically rated critical because exploitation requires no credentials and the code runs with the GitLab service account's privileges.

A rough Patch Tuesday for GitLab

CVE-2026-97229 continues a heavy run of GitLab security work. In January the company fixed a high-severity two-factor authentication bypass, CVE-2026-0723, which let an attacker who knew a target's account ID skip 2FA on Community and Enterprise Edition servers (prior 2FA and denial-of-service fixes).

Last month GitLab addressed another maximum-severity bug, CVE-2026-85706, which allowed unauthenticated attackers to read sensitive data — credentials and other secrets — from vulnerable CE/EE servers (earlier maximum-severity GitLab advisory). A day later, CISA added CVE-2026-85706 to its Known Exploited Vulnerabilities catalog and gave federal agencies three days to secure their systems (CISA KEV alert, CVE-2026-85706 KEV entry). Reporting at the time documented active exploitation (in-the-wild exploitation coverage).

CISA has now flagged five GitLab flaws as exploited in attacks since November 2021, at least one of which was used by ransomware operators (CISA KEV catalog filtered to GitLab). That history is why GitLab's maximum-severity ratings tend to be treated as urgent rather than routine, and why unauthenticated code execution in a service that holds source code, secrets, and pipeline credentials draws immediate attention from both defenders and attackers.

The platform's reach raises the stakes. GitLab says its DevSecOps platform serves more than 70 million registered users and is used by over 50% of Fortune 100 companies, naming Nvidia, T-Mobile, Lockheed Martin, Airbus, and Goldman Sachs among its customers.