GitLab Warns of Max-Severity Code Execution Vulnerability in CI/CD Regex Compiler

GitLab Patches Maximum-Severity RCE in CI/CD Regex Compiler

GitLab warned self-managed users on October 12, 2026 to immediately patch a maximum-severity vulnerability, tracked as CVE-2026-97229 and rated a perfect CVSS 10.0, in the CI/CD Regular Expression Compiler — the component that parses, compiles, and evaluates regular expressions found in a project's pipeline configuration files. GitLab says the flaw stems from an integer overflow caused by insufficient validation of attacker-supplied regular expressions, and that it could let a completely unauthenticated attacker execute arbitrary code on the GitLab server simply by submitting a specially crafted regex inside a CI/CD configuration file. The issue was reported by a researcher using the handle joaxcar through GitLab's HackerOne bug bounty program and is fixed in versions 19.4.2, 19.3.4, and 19.2.8.

Details

How It Works

A crafted regex, not a crafted payload

GitLab's CI/CD configuration format (.gitlab-ci.yml and included pipeline files) supports regular expressions in several places — for example, rules:if conditions and variable matching. The regex compiler built into GitLab is responsible for parsing and compiling those patterns before they can be evaluated against pipeline data. According to GitLab's advisory, "insufficient regular expression validation" in that compiler allows a specially crafted expression to trigger an integer overflow during compilation. Depending on how the overflowed value is subsequently used in memory operations, this class of bug can corrupt adjacent memory and ultimately be leveraged to execute attacker-controlled code on the server hosting GitLab — rather than merely crashing the process or returning bad output.

Why "unauthenticated" matters

Earlier regex-compiler flaws GitLab patched in September 2026 — CVE-2026-93577 (CVSS 9.9, integer overflow) and CVE-2026-89078 (double-free) — both required an authenticated user to trigger the bug, typically someone able to push a pipeline configuration to a repository. CVE-2026-97229 removes that barrier: GitLab's own advisory states it can be exploited by "an unauthenticated user," which significantly widens the pool of potential attackers and the range of exposed surfaces, since any code path that parses an untrusted CI/CD regex without first requiring a login becomes a viable entry point.

Full server compromise, not sandbox escape

Because the vulnerable component runs as part of the core GitLab application rather than inside an isolated CI runner, successful exploitation does not stop at a sandboxed build job — it can hand an attacker code execution on the GitLab server itself. That level of access can expose source code across every hosted repository, CI/CD variables and secrets, deployment keys, and any credentials GitLab is configured to use for downstream systems, making this a potential pivot point into an organization's broader software supply chain.

The third regex-engine critical bug in two months

CVE-2026-97229 is the third critical vulnerability GitLab has had to patch in its CI/CD regex engine since September 2026, following CVE-2026-93577 and CVE-2026-89078. The recurrence suggests the regex compiler has been an area of concentrated security scrutiny — likely from both external researchers and GitLab's own hardening work — and administrators who already patched for the September issues still need this additional, more severe fix.

Impact Assessment

Recommendations

For GitLab administrators

• Patch immediately to 19.4.2, 19.3.4, or 19.2.8 — treat this as an emergency, out-of-cycle change given the unauthenticated CVSS 10.0 rating.
• Prioritize internet-facing self-managed instances first, then internal-only instances.
• If immediate patching is not possible, restrict network access to the GitLab instance (VPN/allowlist only) and disable or tightly review any workflow that lets untrusted users submit CI/CD configuration (e.g., external merge requests that modify .gitlab-ci.yml), as a stopgap only — this does not fully close the gap and should not replace patching.
• Confirm you are also current on the September 23, 2026 fixes (19.4.1, 19.3.3, 19.2.7) for CVE-2026-93577 and CVE-2026-89078; the October patch versions supersede those but any instance still below 19.2.7/19.3.3/19.4.1 has both issues outstanding.

For security teams

• Review recent commits and merge requests for unusual or unusually long/complex regular expressions added to CI/CD configuration files, especially from external or low-trust contributors.
• Rotate CI/CD variables, deployment keys, and any secrets accessible to the GitLab instance if compromise is suspected or cannot be ruled out.
• Check GitLab instance logs for crashes, unexpected process restarts, or anomalous resource spikes in the window before patching, which can indicate failed or successful exploitation attempts.
• Add CVE-2026-97229 to vulnerability-management tracking even if automated scanning hasn't yet flagged it, given the short window between disclosure and likely proof-of-concept publication for CVSS 10.0 issues.

For developers and DevOps engineers

• Avoid writing CI/CD rules that evaluate regular expressions against unsanitized, externally-controlled input (e.g., merge request titles, branch names from forks) until you've confirmed your instance is patched.
• Subscribe to GitLab's security release announcements so critical patches reach your deployment pipeline the same day they're published, rather than waiting for a routine update cycle.
• Treat self-hosted GitLab the same as any other internet-facing production service for patch SLAs — this is the third critical regex-engine RCE in two months.

Key Takeaways

1. CVE-2026-97229 is a maximum-severity, CVSS 10.0 integer overflow in GitLab's CI/CD Regular Expression Compiler that allows unauthenticated remote code execution via a crafted regex in a CI/CD configuration file.
2. It affects self-managed GitLab CE/EE versions 19.2 before 19.2.8, 19.3 before 19.3.4, and 19.4 before 19.4.2 — fixed in 19.4.2, 19.3.4, and 19.2.8, released October 12, 2026.
3. GitLab.com is already patched and GitLab Dedicated customers are not affected; only self-managed instances need to act.
4. This is the third critical vulnerability in GitLab's CI/CD regex engine since September 2026, following CVE-2026-93577 (CVSS 9.9) and CVE-2026-89078 — both of which required authentication, unlike this one.
5. No in-the-wild exploitation or public proof-of-concept has been confirmed as of disclosure, but GitLab's prior maximum-severity flaw (CVE-2026-85706) was added to CISA's KEV catalog and actively probed within a day of patching — administrators should not assume a similar grace period here.
6. The same October 12 release also fixed over 20 additional issues, including a CVSS 8.7 XSS in syntax highlighting and a CVSS 8.5 authorization bypass for protected-branch pipeline execution — a full upgrade, not a single-CVE hotfix, is the recommended path.

Sources

• GitLab warns of max severity code execution vulnerability — BleepingComputer
• GitLab Patches CVE-2026-97229 (CVSS 10.0) Flaw That Lets Unauthenticated Attackers Execute Arbitrary Code — SecurityOnline
• GitLab Critical Patch Release: 19.4.2, 19.3.4, 19.2.8 — GitLab