A regular expression that ends in code execution
When GitLab processes CI/CD configuration, it compiles regular expressions written in the .gitlab-ci.yml file. That compiler contains an integer overflow (CWE-190) that a crafted expression turns into arbitrary code execution. Where it runs matters: the code executes on the GitLab server itself, outside the isolated runners. The attacker lands where the repositories, CI/CD variables and tokens live. GitLab rated the flaw CVSS 10.0 (CVE-2026-97229).
Rapid7 reproduced the attack on an unpatched official GitLab CE image, and working proof-of-concept code is public on GitHub. As of 22 October 2026 no attacks have been confirmed and the flaw is not in the CISA KEV catalog. With a public exploit out, I would not assume that will stay true for long.
No login or an account: what it means for your instance
GitLab and NVD say that under certain conditions no authentication is needed. Rapid7 spells out those conditions: the attacker has to place a malicious .gitlab-ci.yml file on a branch of a public project. If the instance lets ordinary users create public projects, any account will do. With open sign-up anyone can create such an account, so in practice the flaw becomes reachable without logging in.
This gives two levels of urgency:
- Patch today: internet-facing instances with open sign-up, and instances where outsiders (contractors, customers, interns) have accounts and can create public projects.
- Next maintenance window, ideally this week: a typical company instance behind VPN or SSO, with accounts only for employees and no public projects. Here the attack needs a compromised account or an insider. The risk grows with every password leak, but an overnight upgrade is not needed here.
GitLab.com is already patched and GitLab Dedicated customers do not need to do anything. The issue affects self-managed CE and EE, all installation types.
Vulnerable and fixed versions
- 19.4 before 19.4.2
- 19.3 before 19.3.5
- 19.2 before 19.2.8
On the 19.3 branch, skip version 19.3.4. It had a bug on merge request pages with the Ona integration enabled and is not the target fix. Aim for 19.3.5.
The same release fixes 24 flaws in total: 1 critical, 5 high, 14 medium and 4 low. Of the high ones, the most relevant to DevOps teams are CVE-2026-16301 (running pipelines on protected branches without authorization, CVSS 8.5) and CVE-2026-14814 (access to protected CI/CD variables through poisoned cached files, CVSS 8.2). There is also CVE-2026-92883, an XSS in syntax highlighting (CVSS 8.7). CVE-2026-14814 affects all versions before the fixes, so an instance on 19.1 or older is not safe just because CVE-2026-97229 does not cover it. Only the 19.2–19.4 branches received fixes.
Where GitLab tends to hide
The usual blind spots are a test server set up “for a moment”, an old instance left running after a migration, or GitLab in a container on a developer's machine. Check the version like this:
- In the browser: after signing in, the
/helppage or the overview in the Admin Area. - Omnibus (Linux package):
sudo gitlab-rake gitlab:env:info, theVersionline in the GitLab information section. - Docker:
docker ps --format '{{.Names}} {{.Image}}' | grep -i gitlab, thendocker exec -it <container> gitlab-rake gitlab:env:info. Thelatesttag guarantees nothing until the container is recreated from a new image. - Kubernetes (Helm):
helm list -A | grep -i gitlabshows the chart and app version.
While you are there, open the sign-up restrictions in the Admin Area and check who can create public projects. That decides which urgency group the instance falls into.
Upgrade and plan B
The release includes database migrations, so a single-node instance will be briefly unavailable. Take a backup and book a short window.
If you cannot upgrade right away, close the known attack path: disable open sign-up, restrict anonymous access to public projects and take away untrusted users' ability to create or write to public projects. Rapid7 notes that this only blocks the known scenario and does not remove the bug. Treat it as protection for a few days.
What to check in logs and after the upgrade
GitLab published six threat detections for this flaw, including Onigmo native worker crashes, CI lint Workhorse worker crashes and hostile regular expressions sent via GraphQL CI lint. In practice, look for:
- unexpected restarts and crashes of GitLab processes,
- new accounts and new public projects with an unusual
.gitlab-ci.yml, - new access tokens, SSH keys, admin accounts and registered runners that nobody asked for,
- unknown processes on the server.
If the instance was vulnerable and internet-facing with open sign-up, run this review after the upgrade too. The patch closes the flaw but does not remove someone who is already in. At any sign of trouble, rotate tokens and protected CI/CD variables, because they are the most valuable loot.
The longer-term lesson
GitLab ships a new minor version every month, and security fixes go only to the latest branches, in this case 19.2–19.4. An instance that falls a few versions behind eventually stops receiving patches at all. It pays to have a fixed monthly GitLab upgrade slot and an inventory of all instances, test ones included. The settings matter just as much: closed sign-up, public projects only where needed, and a limited group of people who can create projects and run pipelines.