GitLab has released security updates for CVE-2026-97229, a CVSS 10.0 flaw in the regular expression compiler used to process CI/CD pipeline configuration. A specially crafted regular expression triggers an integer overflow that can lead to arbitrary code execution on the GitLab server. Self-managed operators should upgrade immediately; GitLab.com is already patched.

What happened

GitLab’s patch release (19.4.2, with backports to the 19.3 and 19.2 branches) fixes a batch of security issues, the most severe being CVE-2026-97229. Reporting differs on timing: BleepingComputer’s coverage dates the warning to October 12, 2026, while another outlet places the release on October 8. Either way, patches are available now.

The bug was reported by a researcher using the handle joaxcar through GitLab’s HackerOne bug bounty program. As of this writing, GitLab’s advisory does not report exploitation in the wild, and we have not seen the flaw listed in CISA’s KEV catalog.

Technical details

The vulnerable component is the engine that compiles regular expressions found in CI/CD configuration, for example in rules: conditions and only/except matchers in .gitlab-ci.yml. GitLab describes the root cause as weak validation of regular expressions leading to an integer overflow. A crafted expression can cause the compiler to miscompute an allocation or index size, producing memory corruption that an attacker can steer toward code execution in the context of the GitLab application.

The CVSS 10.0 score reflects the advisory’s assessment that an unauthenticated attacker could reach the code path and execute code on the server. Practically, any route by which attacker-controlled regex content reaches the pipeline compiler is a candidate attack surface: project CI configuration, includes from other projects, and merge request pipelines from forks or less-trusted contributors. We have not independently verified the exact preconditions, and GitLab has not published exploit details. Treat the “unauthenticated” characterization with care until a technical write-up appears, particularly on instances with open registration.

Compromise of a GitLab server is rarely contained to the host. The application holds repository contents, CI/CD variables and secrets, deploy keys, runner registration tokens, and the ability to define what runners execute. Code execution on the GitLab server therefore sits upstream of build pipelines and releases, which is why flaws in this class matter for supply-chain integrity.

Affected and fixed versions

BranchFixed in
19.2.x19.2.8
19.3.x19.3.4
19.4.x19.4.2

Both Community Edition and Enterprise Edition are affected. One third-party digest claims the affected range extends back to 18.1, but GitLab’s own listing names only the branches above; confirm against the official advisory for your version. GitLab.com is already running the fixed code, and GitLab Dedicated customers need not take action.

Mitigation

  1. Upgrade self-managed instances to 19.2.8, 19.3.4, 19.4.2 or later. This is the only complete fix.
  2. Restrict exposure while patching. If you cannot upgrade immediately, limit who can reach the instance (VPN or IP allowlist), disable open sign-up, and restrict project creation and fork-based pipelines from untrusted users.
  3. Audit for compromise. Review recent changes to .gitlab-ci.yml files and included templates for unusual or very long regular expressions, check for unexpected processes spawned by the GitLab application user, and review Sidekiq/Puma crashes that might indicate failed exploitation attempts.
  4. Rotate secrets if you suspect exposure. CI/CD variables, runner tokens, deploy keys, personal access tokens and project access tokens should be treated as compromised on any instance showing signs of intrusion.
  5. Check runners. Confirm no unknown runners are registered and that existing runners are not running unreviewed jobs.

Context

This is the second GitLab maximum-severity bug in roughly a month. CVE-2026-85706, a commits API path traversal, was later added to CISA’s KEV catalog after exploitation. Attackers moved on that flaw within hours of the patch, and the same patch-diffing pressure applies here: once the fix is public, the regex-compiler change is a ready-made target for reverse engineering. Self-managed GitLab sits on the critical path for software delivery, so expect rapid weaponization attempts.

References