GitLab patches a CVSS 10 RCE triggered by a crafted regex in a CI/CD pipeline

12 October 2026. GitLab releases versions 19.4.2, 19.3.5 and 19.2.8, fixing 24 issues including CVE-2026-97229. 10.0. The maximum CVSS score on a flaw that allows unauthenticated remote code execution. 25,766. The number of internet-exposed GitLab instances counted by public scanners, while a PoC is already circulating. Why it matters: the vector is neither a binary nor a network service — it’s a pipeline configuration file, text that your developers and forks write every day, and that most teams don’t treat as an attack surface.

The flaw: an integer that overflows in the regex compiler

CVE-2026-97229 is an integer overflow (CWE-190) in the regular expression compiler that GitLab uses to evaluate its CI/CD pipeline rules. In practice, GitLab compiles the regular expressions found in .gitlab-ci.yml files — rules:if conditions, only/except patterns, variable matchers. The problem: a specially crafted regular expression triggers an overflow during compilation, which, with insufficient validation, lets an unauthenticated attacker execute arbitrary code on the GitLab server.

The flaw affects all versions of GitLab CE and EE from 19.2 up to the fixed releases: 19.2.8, 19.3.5 and 19.4.2. An instance on 19.3.2 or 19.4.0 is therefore vulnerable. CERT-EU published advisory 2026-016, and Singapore’s CSA issued alert AL-2026-141. The score is rare: a 10.0 CVSS, the maximum, for an unauthenticated RCE.

Why the pipeline file is the real problem

The severity isn’t the headline — critical RCE bugs in code forges are nothing new — it’s where the trigger lives. The payload sits in a .gitlab-ci.yml file, an artifact GitLab must parse to build the pipeline graph. And that file is, in most organisations, semi-public by design: merge requests from forks carry their own .gitlab-ci.yml, and internal repositories change it constantly.

The result: an attacker looking to cross the perimeter doesn’t need a network exploit against a C service or a privileged account. Depending on your instance’s trust model, they just push a branch or open an MR from a fork containing a malicious regular expression. That’s exactly the scenario defenders fear in software supply chain security: the entry point is legitimate, the content is not.

The fix confirms the reading. GitLab describes the cause as insufficient regular expression validation: the compiler fails to bound a value before using it, and the resulting overflow is exploitable. This isn’t a ReDoS that burns CPU — it’s memory corruption that leads to RCE.

The other 23 fixes aren’t filler

The 12 October batch also patches issues that hit the CI/CD posture directly, even without reaching the flagship’s 10.0. Among them: exposure of protected environment variables, branch protection bypass and privilege escalation. Together they form a familiar chain — a pipeline that leaks a secret, a protection rule that gets skipped, a privilege that gets escalated.

It’s the symptom of a deeper structural problem. Runners execute code on your machines, CI variables carry your secrets, and the pipeline graph decides what ships to production. Each of those layers now has a known flaw in the same patch batch. Treating the patch as a formality leaves three attack paths open instead of one.

What to do, concretely

The fix looks simple: upgrade. But moving from 19.2.x or 19.3.x to a patched release is a migration, not a click, and teams stuck on old minor versions are precisely the ones that will take weeks to move. The public PoC — technical details plus exploit code — shortens that window: don’t assume it stays open until your next scheduled maintenance.

Two immediate actions if you self-host. First, check your version and land on 19.4.2, 19.3.5 or 19.2.8 for your branch. Second, shrink the surface in the meantime: restrict fork-based MRs to trusted projects, and subject incoming .gitlab-ci.yml files to strict review. A regular expression shouldn’t run on your server before a human has read it.

Longer term, change the mental model. A pipeline file is code executed by your forge, not a mere configuration file. It deserves the same policy: code review, tests, provenance, and above all the same trust boundary. Today’s flaw is a regex compiler; tomorrow’s could be a YAML parser or a template engine.

Verdict

If you self-host GitLab, treat this as an emergency: a 10.0 CVSS, a public PoC and 25,000+ exposed instances leave no room to wait, and the fork vector widens the circle of potential attackers. If you’re on GitLab.com, the fix is already applied on the host side — focus instead on reviewing the .gitlab-ci.yml files of fork MRs and rotating CI variables if a suspicious pipeline ever ran. Either way, the lesson is the same: your pipeline configuration is part of your attack surface, and it grows with every fork you accept.

References

• GitLab — Critical Patch Release: 19.4.2, 19.3.5, 19.2.8 (12 October 2026)
• OpenCVE — CVE-2026-97229
• CERT-EU — Security Advisory 2026-016, Critical Vulnerability in GitLab CE and EE
• CSA Singapore — Alert AL-2026-141
• DevOps.com — GitLab Fixes CVSS 10 Flaw in CI/CD Regex Engine, Plus 23 Other Vulnerabilities