GitLab CVE-2026-97229: Critical CVSS 10.0 RCE in the CI/CD Regex Compiler

GitLab CVE-2026-97229 critical RCE vulnerability (CVSS 10.0)

What Is CVE-2026-97229?

On October 12, 2026, GitLab released a critical patch for Community Edition (CE) and Enterprise Edition (EE) covering versions 19.4.2, 19.3.5, and 19.2.8. The most important fix in this release addresses CVE-2026-97229, which carries a CVSS v3.1 score of 10.0 (Critical). According to GitLab’s official advisory, under certain conditions this vulnerability could allow an unauthenticated user to execute arbitrary code on the GitLab server through a specially crafted regular expression placed in a CI/CD configuration. GitLab attributes the root cause to insufficient regular expression validation, and the issue is classified as an integer overflow (CWE-190) in the CI/CD Regular Expression Compiler component. The vulnerability was reported by Johan Carlsson (joaxcar) through HackerOne.

The same release also fixes a number of other vulnerabilities, including CVE-2026-92883 (cross-site scripting in syntax-highlighted output, CVSS 8.7 – High) and CVE-2026-16301 (improper authorization in the downstream pipeline creation service, CVSS 8.5 – High). Both of these require an authenticated user and do not belong to the same impact class as CVE-2026-97229. This follows our earlier analysis of the GitLab GraphQL vulnerabilities.

Current Status (October 13, 2026)

Rapid7 independently reproduced the vulnerability on an unpatched GitLab 19.4.1 CE instance and confirmed code execution. However, there is no confirmed in-the-wild exploitation and no public proof of concept (PoC) at this time. GitLab.com is already running the patched version; self-managed installations should be upgraded immediately.

Technical Analysis

Because the vulnerability was disclosed only recently and may quickly become a target for exploitation attempts, this article does not share PoC code, exploit input, or dynamic analysis (debugger) output; instead, we examine the mechanism from a defensive perspective. Throughout this section we deliberately distinguish between two types of information: what GitLab’s official advisory states, and the technical details based on Rapid7’s independent research. GitLab plans to make the issue details public 90 days after the patch release, so technical details from official sources are limited for now.

Regular Expressions in .gitlab-ci.yml

When managing CI/CD processes, GitLab evaluates the conditions defined in the .gitlab-ci.yml file. Regular expressions can appear in several places in this file, such as =~ and !~ comparisons in rules:if expressions or patterns defined under only / except. GitLab has not disclosed exactly which part of the configuration must contain the triggering regex.

GitLab's Official Description

GitLab’s advisory states that, due to insufficient validation, a specially crafted regex in a CI/CD configuration could, under certain conditions, allow an unauthenticated user to execute arbitrary code on the server. The advisory does not describe the memory-level mechanism.

Rapid7's Independent Analysis: The Exploit Chain

According to Rapid7’s analysis dated October 13, 2026, the exploitation chain consists of the following stages:

Validation stage: The attacker-crafted regex is first compiled in a compact US-ASCII representation and passes GitLab’s validation.
Encoding-dependent recompilation: When the same regex is evaluated against a specially formed repository path containing valid UTF-8 characters, Onigmo, Ruby’s regular expression engine, recompiles the expression for the new encoding — after validation has already completed.
Integer overflow: During recompilation, an integer overflow in the compiler’s program-size calculation causes invalid regex instructions to be generated.
Code execution: The resulting loss of control-flow integrity allows the attacker to run attacker-controlled Onigmo VM operations within the Ruby process. Rapid7 confirmed that this path can be used to execute operating system commands in the context of GitLab’s git user.

Rapid7 reproduced code execution on the official GitLab 19.4.1 CE (Linux amd64) image with ASLR enabled, and showed that the same input did not execute on the patched 19.4.2 image. Rapid7 states that further details on the root cause and exploitation chain will be published in a separate technical analysis.

Patch Notes Observation (Unconfirmed)

The bug fixes section of GitLab’s release notes lists patches to the Ruby 3.3 and 3.4 regexp component for all three release branches, one of which concerns program-size calculation. Although this fix appears to touch the same area as the mechanism Rapid7 describes, GitLab has not drawn any connection between these patches and CVE-2026-97229. This link is therefore our own inference and should not be read as confirmed, official information.

Integer Overflow Is Not a Heap Overflow

An integer overflow can lead to memory safety issues, but the mechanism in between must be demonstrated separately. Current sources do not describe this vulnerability as a classic heap buffer overflow or pointer-overwrite scenario. The confirmed root cause is an overflow in the regex compiler’s program-size calculation and the invalid regex instructions it produces.

Attack Prerequisites: What "Unauthenticated" Really Means

The CVSS vector specifies the privileges required as PR:N (none). In practice, however, exploitation depends on whether the attacker can place a malicious CI/CD configuration where it will be processed. In the scenario Rapid7 validated, the attacker must be able to commit a malicious .gitlab-ci.yml file and a specially formed UTF-8 repository path to a branch in a public project. On self-managed instances where users can self-register and create projects, an ordinary account satisfies this prerequisite, which effectively removes it. The description “unauthenticated exploitation” is therefore accurate, but it should not be read as meaning RCE is achievable on every installation without any additional prerequisites.

Security Impact and Risk

The CVSS v3.1 vector for CVE-2026-97229 is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: the vulnerability is exploitable over the network with low complexity, requires no privileges or user interaction, involves a scope change (Scope: Changed), and has a high potential impact on confidentiality, integrity, and availability. Successful exploitation results in unauthorized command execution on the GitLab server in the context of the git user. This does not automatically mean root access; however, because the git user has broad access to GitLab application data and configuration, the organizational impact is high. Possible consequences include:

Source code and secrets: Depending on the server’s access rights and configuration, access to repositories, CI/CD variables, tokens, and other sensitive data.
CI/CD supply chain risk: Compromise of the integrity of the software produced, through manipulation of pipeline configurations or build processes.
Corporate network risk: Use of the server as a pivot point for lateral movement to other systems it can reach.
Service continuity: Disruption of GitLab services or CI/CD workflows.

Whether these consequences materialize depends on the privileges the attacker obtains, the GitLab runtime environment, and additional security controls such as network segmentation. The highest risk lies with self-managed instances that are internet-facing, allow user sign-up, and let users create public projects. Although active exploitation has not yet been confirmed, the time pressure is high: as The Hacker News notes, in-the-wild probing of another CVSS 10.0 GitLab vulnerability disclosed last month (CVE-2026-85706) was observed within hours of its disclosure.

Fixed Versions and How to Patch

GitLab.com is already running the patched version, and GitLab Dedicated customers do not need to take any action. Organizations hosting GitLab on their own servers (self-managed) must upgrade immediately to one of the fixed versions below.

Affected Version Range	Fixed Version
19.2.x (before 19.2.8)	19.2.8
19.3.x (before 19.3.5)	19.3.5
19.4.x (before 19.4.2)	19.4.2

According to the official advisory, CVE-2026-97229 affects only the 19.2 and later release branches. Organizations running older versions are not directly affected by this CVE but may be affected by other vulnerabilities fixed in the same release, and should plan a move to a supported version. The patch includes database migrations: single-node instances will experience downtime during the upgrade, while multi-node instances can be upgraded using the zero-downtime procedure. Version 19.3.5 also includes post-deploy migrations.

Recommended Actions

Inventory: Identify the version and deployment type (Linux package, Helm chart, Docker, etc.) of every self-managed GitLab installation, prioritizing internet-facing instances.
Upgrade: Upgrade affected installations to the corresponding fixed version as soon as possible.
Interim mitigation: If the patch cannot be applied immediately, restrict anonymous access to public projects, disable user self-registration or require administrator approval, and revoke untrusted users’ ability to create or write to public projects. Important: These measures do not fix the vulnerability and are not a substitute for the patch. They only reduce the availability of the attack path demonstrated by Rapid7 (committing a malicious CI/CD configuration to a public project); the flaw in the regex compiler remains, and the absence of other attack paths cannot be assumed. The patch should be applied as soon as possible.
Review: After upgrading, and in line with your organization’s incident response procedures, review recently added or modified .gitlab-ci.yml files (especially those containing unusual regexes), repository paths containing unusual UTF-8 characters, newly created public projects, and unexpected processes spawned by the git user. Since Rapid7’s analysis does not include official IOCs, these items are general threat-hunting recommendations.
Follow-up: Track Rapid7’s forthcoming detailed technical analysis and the issue details GitLab will publish after 90 days, and update your detection rules accordingly.

References

Subscribe to our cyber security newsletter

Scroll to top