GitLab CVE-2026-97229 is a CVSS 10.0 integer overflow in the CI/CD regex compiler. Rapid7 got code execution on 19.4.1. Upgrade to 19.2.8, 19.3.5 or 19.4.2.
GitLab patched CVE-2026-97229 on 12 October 2026: an integer overflow in the CI/CD regular expression compiler of GitLab CE and EE that can give an attacker code execution on the server. NVD scores it CVSS 10.0. Self-managed instances on 19.2, 19.3 and 19.4 need 19.2.8, 19.3.5 or 19.4.2; GitLab lists no workaround. Rapid7 reproduced code execution on 19.4.1, and no exploitation has been confirmed. Rapid7 has also published a proof-of-concept repository, so patching should not wait.
What happened
GitLab shipped patch releases 19.2.8, 19.3.5 and 19.4.2 on 2026-10-12. The advisory describes an integer overflow in the CI/CD regular expression compiler that affects GitLab CE/EE. NVD published the record on 2026-10-13 as CWE-190 (Integer Overflow or Wraparound) with a CVSS 3.1 score of 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), scored by GitLab as CNA. NVD's description says an unauthenticated user could execute arbitrary code on the GitLab server through a specially crafted regular expression in a CI/CD configuration. GitLab credits the reporter, joaxcar, through its HackerOne bug bounty program.
Rapid7 published an analysis the same day (it added a link to its own public PoC repository on 13 October; we link it and do not reproduce any code) and said it reproduced code execution against the unpatched official GitLab CE container image at 19.4.1, with ASLR enabled. The patched 19.4.2 image resisted the same input.
GitLab.com already runs the fixed version, and GitLab Dedicated customers need to do nothing. The exposure is self-managed installs.
Who is exposed
| Branch | Affected | Fixed in |
|---|---|---|
| 19.2 | before 19.2.8 | 19.2.8 |
| 19.3 | before 19.3.5 | 19.3.5 |
| 19.4 | before 19.4.2 | 19.4.2 |
Some secondary coverage gives 19.3.4 as the fixed build. NVD, GitLab's advisory and Rapid7 all say 19.3.5, which is the figure used here. Releases outside these three branches are not listed as affected by NVD; one outlet claims everything from 19.1 onward is vulnerable, but that is not in the NVD record or GitLab's advisory.
The score says "no privileges required", but Rapid7 describes a narrower practical path. Confirmed (Rapid7): the attacker must be able to commit a malicious .gitlab-ci.yml and a repository path containing UTF-8 characters to a branch in a public project. Confirmed (Rapid7): on instances that allow self-registration and project creation, that prerequisite is easy to meet, so an outsider can satisfy it without an invitation.
Inference (not stated in these words by a source): instances with open sign-up, or with public projects that untrusted users can write to, are the most exposed. Instances that disable sign-up and keep projects private raise the bar, but the sources do not say they are safe. CISA's SSVC entry (2026-10-14) rates exploitation "none", automatable "yes" and technical impact "total", which fits a flaw that is simple to script once the conditions are met.
Technical details
Per Rapid7, GitLab's CI/CD handling relies on Ruby's Onigmo regular expression engine. After an initial validation passes, Onigmo recompiles the pattern when it processes UTF-8 encoded paths. An integer overflow in the compiler's program-size calculation then produces invalid regex instructions, the process loses control-flow integrity, and the attacker gets arbitrary code execution in the context of the GitLab git user.
That account matters for impact. The git user runs GitLab's application processes on the server, so code execution there is a foothold on a system that holds source code, CI variables and credentials. This article does not describe what Rapid7 did after getting execution, because Rapid7's post is the source for that, and exploit code is not reproduced here.
What admins should do
- Upgrade self-managed GitLab CE/EE to 19.2.8, 19.3.5 or 19.4.2, whichever matches your branch. GitLab lists no workaround, so patching is the remedy.
- Plan the downtime. This was a critical patch release covering 24 CVEs, and GitLab notes that on single-node self-managed installs, upgrades cause downtime because migrations must complete before GitLab can start.
- Prioritise internet-facing instances with open registration or public projects. Those match the conditions Rapid7 describes.
- Until you are patched, Rapid7 lists interim controls: restricting anonymous access to public projects and preventing untrusted users from creating or writing to public projects. Rapid7's own caveat is that these address only the demonstrated delivery path and do not remediate the vulnerable regular expression compiler, so they do not replace the upgrade.
- Review after patching (our GitLab incident recovery runbook covers an earlier GitLab compromise) for unexpected projects or branches from new accounts, and CI configuration files with unusual regular expressions or non-ASCII repository paths. This is a hunting suggestion; no indicators of compromise have been published.
- Do nothing special on GitLab.com or Dedicated. GitLab says both are covered.
What is still unclear
- No exploitation in the wild is confirmed: Rapid7 reported none as of 2026-10-13, CISA's SSVC entry says exploitation "none", and the CVE is not in CISA's Known Exploited Vulnerabilities catalog (catalog version 2026.10.14, checked 2026-10-15). With a public technical analysis and a CVSS 10.0, that status can change quickly.
- No public indicators of compromise or detection rules have been published in the sources reviewed.
- It is not clear whether instances with sign-up disabled and only private projects can be reached by any other route. The sources describe the public-project path only.
- Resolved: NVD calls the flaw unauthenticated, while Rapid7's reproduction needs a malicious CI configuration already planted in a repository. Rapid7 reconciles the two: the trigger itself is unauthenticated, but the attacker first needs a way to commit, and on instances that allow self-registration that requirement is effectively removed.
For another recent GitLab flaw that touched self-hosted components, see our coverage of the GitLab AI Gateway CVE-2026-90970 Duo agent sandbox escape.