Your SIEM holds logs. Your GitLab holds the keys that make those logs matter: CI secrets, runner tokens, deploy keys, package credentials. A CVSS 10.0 on the CI/CD regex compiler is not a developer inconvenience. It is a supply-chain root compromise waiting for a public project.
GitLab patched CVE-2026-97229 on Oct 12. The bug is an integer overflow in the CI/CD Regular Expression Compiler. Under certain conditions, a specially crafted regular expression in a CI/CD configuration can lead to arbitrary code execution on the GitLab server. GitLab scored it CVSS 3.1 at 10.0: network, low complexity, no privileges, no user interaction, scope changed (CVE.org; GitLab).
Who is actually exposed. Self-managed GitLab CE and EE from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2. Fixed builds are 19.2.8, 19.3.5 and 19.4.2. GitLab.com is already patched. GitLab Dedicated customers do not need to act (GitLab; Rapid7). If you run your own GitLab, you are the patch cycle.
Rapid7 reproduced full code execution on an unpatched official 19.4.1 CE image and added the important footnote the CVSS string papers over. The vendor vector reads fully unauthenticated. In Rapid7’s chain, an attacker still needs a way to plant a malicious .gitlab-ci.yml and a UTF-8 repository path in a public project first. On instances that allow self-registration and public project creation, that prerequisite is free (Rapid7). That is not a comfort. That is the default on a lot of internal GitLabs that never got hardened after the POC phase.
How the bug bites. The crafted regex passes GitLab’s validation in a compact US-ASCII form. When Ruby’s Onigmo engine recompiles it against a UTF-8 path, an integer overflow in program-size calculation produces bad instructions. Control flow breaks inside the regex VM, and the process can run a system command as the GitLab git user (Rapid7). No phishing. No stolen admin cookie. A regex and a path.
Context makes this worse. Last month GitLab fixed another maximum-severity issue, CVE-2026-85706, that CISA then added to the Known Exploited Vulnerabilities catalog with a three-day federal due date. CISA has flagged five GitLab flaws abused since November 2021, including one used by ransomware groups (BleepingComputer). GitLab says more than 30 million registered users and over half of the Fortune 100 touch the platform (BleepingComputer, citing GitLab). When the forge falls, every pipeline secret is in play.
What we’d do before lunch. Inventory every self-managed GitLab and note the exact version. Upgrade to 19.2.8, 19.3.5 or 19.4.2 outside the normal change window. Until you patch, turn off public signup, lock who can create public projects, and stop untrusted users from writing CI config on shared instances (Rapid7). Then rotate CI/CD variables, runner tokens and deploy keys that lived on the box while it was vulnerable. Patching without rotating is half a cleanup.
Also ask the boring ownership question. Who owns GitLab in your company: platform engineering, AppSec, or “the team that stood it up in 2019”? RCE on the forge is an AppSec incident that looks like an infra ticket. Treat it like crown-jewel compromise, because that is what the secrets on that host are.
The read. Agent platforms and AI coding tools are multiplying the number of identities that can write CI config. The regex compiler just reminded everyone that the forge is still the highest-value server in the software factory. Patch it like you would patch a domain controller.