If you self-host GitLab — Community or Enterprise Edition — this is a stop-and-patch alert. CISA confirmed on October 29 that a maximum-severity flaw in GitLab’s CI/CD regular-expression compiler is being actively exploited in the wild and added it to its Known Exploited Vulnerabilities (KEV) catalog. Tracked as CVE-2026-97229 and rated CVSS 10.0, it lets a completely unauthenticated attacker run arbitrary code on your GitLab server with a single crafted pipeline configuration. If your instance is behind on patches, assume it is already being probed.

What the flaw is

CVE-2026-97229 is an integer overflow (CWE-190) in GitLab’s CI/CD Regular Expression Compiler — the component that parses, compiles, and evaluates regular expressions in pipeline configuration files (.gitlab-ci.yml). Because it does not properly validate the expressions it processes, a specially crafted regular expression triggers an integer wraparound that corrupts memory and leads to arbitrary code execution on the server. No credentials, no authentication, and no interaction with a user are required.

The bug was discovered by security researcher “joaxcar” through GitLab’s HackerOne bug-bounty program.

Why it matters

This is your source-code and CI/CD platform. A successful exploit means the attacker owns the server that holds your repositories, secrets, deployment pipelines, and — critically — the infrastructure your pipelines build and deploy into. From a rooted GitLab box an attacker can steal credentials and API tokens, tamper with source code, inject malicious code into your build chains, and pivot from there into whatever your runners can reach. Unauthenticated, pre-auth code execution on your code-hosting platform is about as bad as it gets, and that combination is exactly why this flaw is graded a perfect 10.0.

Active exploitation

On October 20-21, Alpine Linux publicly disclosed an attack against its own unpatched instance. The attacker pushed crafted CI configurations that crashed GitLab worker processes eight times; in four of those crashes the exploit moved to its next stage. The attacker also pulled down Alpine’s GitLab container image. Alpine rebuilt the instance from scratch, saying it found no evidence the compromise had succeeded but could not rule it out.

CISA added CVE-2026-97229 to its KEV catalog on October 29 and ordered federal agencies to remediate by November 1, per Binding Operational Directive 26-04. The exposure is broad: internet-facing GitLab Community Edition instances number in the thousands — Shadowserver tracks roughly 2,800 — and the scanning is happening now.

And this is not GitLab’s first high-severity issue this year. In January it patched a high-severity two-factor-authentication bypass (CVE-2026-0723). Earlier this month it fixed another maximum-severity Regular Expression Compiler flaw (CVE-2026-110264), then a max-severity path traversal in the repository commits API (CVE-2026-85706) that can leak credentials and other secrets — which CISA added to KEV a day later after researchers caught attackers scanning for unpatched instances. CISA has now tagged six GitLab vulnerabilities as exploited in the wild since November 2021. If your GitLab is old, it is a target.

What to do

1. Update now. Patched versions are GitLab CE/EE 19.4.2, 19.3.5, and 19.2.8. Upgrade immediately — do not wait for a change window. If you are on an older or unsupported line, get to a supported release first, then apply the fix.
2. Investigate for prior compromise. If your instance was publicly exposed and unpatched before this, check for suspicious pipeline activity, unexpected CI runs, worker process crashes, newly added credentials or CI variables, web shells, and unusual outbound connections. Treat the box as compromised until you can account for it.
3. Rotate credentials and tokens. Any API tokens, deploy keys, runner registration tokens, or secrets that lived in the instance should be rotated after upgrading — an attacker with code execution can grab all of them.
4. Restrict access. Keep GitLab management and login surfaces off the public internet where possible, behind a VPN or IP allow-list, and enforce single sign-on with strong multi-factor authentication.
5. Treat existing builds as untrusted. Containers and build logs produced before the patch should be handled carefully until you are confident the environment was clean.

If you self-host GitLab, the fix has been out since earlier this month and attackers are already exploiting the flaw. Patch to 19.4.2, 19.3.5, or 19.2.8 today, hunt for signs of intrusion, and rotate anything that touched that server.