GitLab CVE-2026-97229: CI regex RCE, now in KEV

GitLab patched CVE-2026-97229 on 12 October 2026. For two weeks the public reporting said the same thing: maximum severity, proof of concept reproduced, no confirmed exploitation. That changed on 29 October, when CISA added it to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of 1 November: three days.

If you run a self-managed GitLab instance and haven't upgraded since early October, this is the one to do today. GitLab.com and GitLab Dedicated are already patched and need no action.

What the vulnerability is

From GitLab's critical patch release of 12 October:

• Component: the CI/CD regular expression compiler, in both Community and Enterprise Edition.
• Weakness: an integer overflow (CWE-190) caused by insufficient validation of regular expressions in CI/CD configuration.
• Impact: under certain conditions, an unauthenticated user can execute arbitrary code on the GitLab server.
• Score: CVSS 3.1 10.0, AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The changed scope reflects that code runs on the server itself, not in a sandboxed CI job.
• Credit: reported through GitLab's HackerOne programme by the researcher joaxcar.

Code execution on a GitLab server is about as bad as it gets for a software company. The server holds your source, CI/CD variables (often cloud keys and deploy tokens), runner registration tokens and container registry credentials. An attacker there can read all of it, and can change code before it ships.

Affected and fixed versions

Release line	Affected	First fixed version
19.4	before 19.4.2	19.4.2
19.3	before 19.3.5	19.3.5
19.2	before 19.2.8	19.2.8

Some early coverage, including BleepingComputer's, listed 19.3.4 as the fix for the 19.3 line. GitLab's own release page and Rapid7's advisory both give 19.3.5. Go by the vendor: treat 19.3.4 as vulnerable.

Don't stop at the first fixed version. GitLab has shipped two more security releases since: another critical patch release on 21 October, and on 29 October 19.5.3, 19.4.5, 19.3.7 and 19.2.10 among others. Upgrade to the latest patch on your release line. GitLab's 29 October notes also say self-hosted GitLab Runner and AI Gateway need their own upgrades, so check those components too.

"Unauthenticated" has a condition attached

GitLab rates the flaw as needing no privileges. Rapid7, who reproduced code execution on an unpatched official GitLab CE image, describe the delivery path they demonstrated more precisely: the attacker commits a malicious .gitlab-ci.yml, plus a repository path containing UTF-8 characters, to a branch in a public project.

That turns the real question into: who can create or push to a public project on your instance?

• Open sign-up. If anyone on the internet can register and create projects, the condition is met by anyone. Rapid7 say this effectively removes the constraint.
• Closed sign-up. Any existing account that can create a public project is enough. That includes contractors, old accounts nobody disabled, and any account whose password has leaked.
• No public projects at all. This narrows the demonstrated path. It does not fix the bug, and the vendor's "certain conditions" wording does not rule out other routes.

What to do, in order

1. Find every self-managed GitLab you own. The production instance is the easy one. The forgotten ones are the risk: a staging copy, an old instance kept "read-only" after a migration, a team's own install on a cloud VM. Check DNS for names like gitlab., git. and code., and check cloud accounts for GitLab marketplace images.
2. Check the version. As an administrator, the Admin area shows the running version. Compare it with the table above.
3. Upgrade to the latest patch on your release line, not just the first fixed one. If you are on a line older than 19.2, check GitLab's advisory for whether that line is affected and supported. Don't assume.
4. If you cannot upgrade today, apply Rapid7's interim steps: restrict anonymous access to public projects and stop untrusted users from creating or writing to public projects. In the Admin area that usually means turning off open sign-up and restricting the Public visibility level. Rapid7 are explicit that this blocks the demonstrated delivery path only. Upgrading is the fix.
5. Look for signs it already happened. GitLab's release notes name six threat detections for self-managed instances, among them crashes of the Onigmo native worker and of the CI lint workhorse worker, and rejections by the CI regexp guard. Check logs since 12 October for those, for unexpected public projects or new accounts, and for pipeline configurations you don't recognise.
6. If you find anything, assume the secrets are gone. Rotate CI/CD variables, deploy tokens, runner registration tokens and any cloud credentials the instance could read. Patching closes the hole; it does not take back keys that have already been copied.

Why exposed GitLab instances get hit fast

A code-hosting server is designed to be reachable by developers, so it often ends up reachable by everyone. A public HTTPS login page is normal for GitLab. That's why the inventory step matters most: you can't patch the instance you don't know is answering on a public address. We wrote about this gap in what counts as your external attack surface. For the services that should never be public at all, see ports that should never face the internet.

Where CyberSpec fits, and where it doesn't

CyberSpec does not run a test for CVE-2026-97229, and it does not try to exploit anything. What a full scan of your verified domains, IPs and ranges does is check all 65,535 ports and produce an inventory of the services answering on them. A web service on a host you'd forgotten about shows up there, so you can identify it, and if it is GitLab, put it on the upgrade list. The version check and the upgrade still happen in GitLab.

See how network scanning works.