Vulnerabilities
GitLab CI regex flaw runs code on the server: patch now
CVE-2026-97229 (CVSS 10.0) lets a crafted regex in .gitlab-ci.yml run commands on self-managed GitLab. Fixed versions, who is exposed, checks and interim steps.
GitLab released 19.4.2, 19.3.5 and 19.2.8 on October 12 to fix CVE-2026-97229, a CVSS 10.0 integer overflow in the component that compiles regular expressions found in CI/CD pipeline configuration. A crafted regex in a .gitlab-ci.yml file can end in code execution on the GitLab server itself. Every self-managed Community Edition (CE) and Enterprise Edition (EE) instance on 19.2 before 19.2.8, 19.3 before 19.3.5 or 19.4 before 19.4.2 is affected. GitLab.com is already patched and GitLab Dedicated customers need do nothing.
GitLab's advisory says an unauthenticated user could trigger it "under certain conditions". Rapid7 reproduced code execution on October 13 and found what those conditions are: the attacker needs to commit a malicious pipeline file to a branch in a public project. On an instance where anyone can sign up and create a public project, that is a free account away. Rapid7 has also published a proof of concept on GitHub.
How it works
Pipeline configuration accepts regular expressions in several places, for example to decide which branches or file paths a job runs on. GitLab validates those expressions before using them, then hands them to Onigmo, the regex engine built into Ruby, which the GitLab Rails application runs on. Onigmo compiles each pattern into a small program of instructions for its own virtual machine and executes that program against the text being matched.
According to Rapid7, the crafted regex is compact enough to compile in US-ASCII form, and in that form it passes GitLab's validation. When the same pattern is later matched against a repository path containing valid UTF-8 characters, Onigmo recompiles it for the new encoding. That second compile happens after validation is over, and in it the calculation of the program's size overflows an integer, so the compiler emits invalid instructions. Rapid7 says the resulting loss of control-flow integrity lets the attacker drive Onigmo's virtual machine and run an operating system command as the git user, the account the GitLab application runs under.
GitLab's score marks the scope as changed (S:C in the vector), meaning the damage reaches beyond the regex component. SOCRadar lists what is in reach from the server's context: source code, CI/CD variables, access tokens, registries and credentials, and through them the connected runners, cloud environments and deployment systems.
The CVSS vector says no privileges are needed. Rapid7's reproduction says otherwise in practice: an attacker must first be able to plant the .gitlab-ci.yml and the UTF-8 path on a branch of a public project. That turns this into an unauthenticated attack only on instances that allow open self-registration and public project creation. Elsewhere it still works for any user who can write to a public project, including an insider or a stolen low-privilege account.
What attackers are doing
As of October 13, Rapid7 and SOCRadar both reported no confirmed exploitation in the wild, and CISA had not added the flaw to its Known Exploited Vulnerabilities (KEV) catalog when Cybersecurity Dive checked on October 12.
A public proof of concept raises the odds. Rapid7 validated the full chain on the official GitLab CE 19.4.1 Linux amd64 image with address space layout randomisation (ASLR) on, confirmed the same input fails on 19.4.2, and linked a public proof of concept from its write-up. The README of that proof of concept says it was tested only on that image and that other builds need adjusted offsets, which slows attackers down without stopping them. Last month's GitLab flaw, CVE-2026-85706, went onto the KEV list one day after GitLab fixed it.
The researcher who reported the bug, joaxcar, did so through GitLab's HackerOne bug bounty program.
What to do
1. Upgrade
Move to 19.4.2, 19.3.5 or 19.2.8, or later. Some early coverage listed 19.3.4 for the 19.3 branch; GitLab's release page now points to 19.3.5, because 19.3.4 broke merge request pages when the Ona integration was enabled. The release contains database migrations, so a single-node instance stays down until they finish, while multi-node deployments can follow GitLab's zero-downtime upgrade procedure. On Kubernetes, confirm the running GitLab version under Admin > Help or /api/v4/version, since Helm chart numbers differ from GitLab version numbers.
GitLab lists 19.2 as the earliest affected branch. A few secondary reports gave earlier starting versions (19.1, or 18.1), which GitLab's advisory does not support. Older instances get no security fixes from GitLab, which only patches the three latest minor releases, so they need upgrading regardless.
2. If you cannot upgrade today
Rapid7's interim advice is to restrict anonymous access to public projects and stop untrusted users from creating or writing to them. Rapid7 is explicit that this blocks the delivery path it demonstrated and does not fix the vulnerable compiler, so use it to cover the days until the upgrade lands. In the admin area under Settings > General:
- Under "New user account restrictions", clear "Allow new user accounts", or select "Require admin approval for new user accounts".
- Under "Visibility and access controls", add Public to "Restricted visibility levels" so only administrators can create public projects. GitLab's documentation says this setting does not cover projects created in personal namespaces, and it does not change projects that are already public.
- List existing public projects with
GET /api/v4/projects?visibility=publicand switch any that do not need to be public to internal or private. On the ones that stay public, review who has Developer access or above, since those users can push branches.
3. Check whether someone got there first
GitLab has not published indicators for this flaw, so these checks follow the preconditions Rapid7 describes:
- New accounts:
GET /api/v4/users?created_after=2026-10-01as an administrator, and compare against expected sign-ups. - Public projects created or active since the start of October:
GET /api/v4/projects?visibility=public&last_activity_after=2026-10-01T00:00:00Z. In each, look for branches that add or change.gitlab-ci.ymlalongside files or directories with unusual non-ASCII names. - Worker crashes: the proof of concept's README says successful runs come with Puma worker crashes and restarts, which show in
/var/log/gitlab/puma/puma_stderr.logon Linux package installs. - Processes and network: shells,
curl,wgetor interpreters started under thegituser by a Puma process (ps -u git -o pid,ppid,etime,cmd), and outbound connections from the GitLab host to addresses it has no reason to reach.
4. If you find signs of compromise
Preserve /var/log/gitlab and any host or firewall logs first. Rebuild the server on a fixed version rather than patching in place, because a command run as git can change application files. Then rotate what the instance held: CI/CD variables at instance, group and project level, personal, project and group access tokens, deploy tokens and keys, runner authentication tokens, and the credentials of any cloud or deployment integration the instance connects to.
The wider lesson
Two settings that many teams never revisit, open sign-up and who may create public projects, decided whether this CVSS 10.0 flaw needed an account or not. An instance that only serves employees rarely needs either, and with both closed, the next bug of this kind needs a valid internal account to reach. Add those settings, and the list of users who can push to public projects, to the checklist you run at every GitLab upgrade.
We help teams run and upgrade self-managed platforms like GitLab, including secret rotation after an incident, through our platform and cloud engineering work, and our attack surface management service flags instances with open registration exposed to the internet. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.
Sources: GitLab patch release 19.4.2, 19.3.5, 19.2.8, Rapid7, Rapid7 proof of concept README, Help Net Security, BleepingComputer, Cybersecurity Dive, Cyber Daily, SOCRadar, GitLab visibility and access controls, GitLab sign-up restrictions.