GitLab patches maximum severity code execution flaw

GitLab released security patches on October 21 for CVE-2026-110264, a maximum-severity integer overflow in the regular expression compiler that could allow a remote attacker without credentials to run arbitrary code on exposed self-managed GitLab Community Edition and Enterprise Edition servers ^[1][2][3]. The vulnerability was reported by security researcher 'joaxcar' through GitLab's HackerOne bug bounty program; The Register identifies the researcher as Johan Carlsson ^[1][2][3].

According to GitLab's release notes and SOC Prime's analysis, the vulnerable code dates to GitLab 7.0, released in June 2014, so roughly 12 years of CE and EE releases are affected. Patched versions are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13; GitLab states that all vulnerable installations should be upgraded to one of these releases as soon as possible ^[1][2][3].

Shadowserver's dashboard lists more than 2,700 internet-facing GitLab Community Edition servers, but the organization does not state how many are honeypots or already patched ^[1].

GitLab.com has the patched release, and GitLab Dedicated tenants on internal builds 19.3.5-internal0, 19.4.2-internal0, or newer already contain the fixes, the company says. For self-managed installations, GitLab published two threat detections: one named 'Onigmo native worker crash' and another named 'Org mode render error burst' ^[1][2][3].

The new flaw is distinct from CVE-2026-97229, an earlier GitLab RCE found in regex handling and fixed in October, which affected fewer recent versions. It also differs from CVE-2026-85706, which BleepingComputer describes as allowing unauthenticated attackers to read sensitive data; CISA added that flaw to its known exploited vulnerabilities catalog and required federal agencies to patch it within three days ^[1][2][3].

As of October 22, 2026, neither GitLab nor the cited reports have seen active exploitation. SOC Prime notes there is no public proof of concept, and GitLab generally withholds detailed information for 90 days after a fix to allow patching ^[2][3].

SOC Prime warned that server-level compromise could lead to credential theft, tampering with repositories, supply chain attacks, persistence, or lateral movement, because GitLab repositories often hold source code, CI/CD configuration, deployment secrets, and access tokens ^[2][3].

Defenders should upgrade immediately, then review GitLab's two published detections and look for unusual activity: application crashes, bursts of rendering errors, suspicious processes launched by GitLab or Ruby, unexpected shell execution, new SSH keys or administrative accounts, modifications to runners, deploy tokens, personal access tokens, project access tokens, or unusual outbound traffic. If an instance shows signs of compromise, administrators should isolate the machine, keep logs and forensic data, rotate any secrets that may have been exposed, and check the integrity of repositories and CI/CD pipelines before bringing it back online ^[3].

Update, October 22, 2026

The Register's October 22 report adds GitLab's own scale figures: the company says it has 50 million registered users and that more than half of the Fortune 100 use its platform ^[4]. The same report notes that last month attackers began exploiting a different maximum-severity flaw in GitLab CE and EE within days after the vendor released a patch, according to CISA and private researchers ^[4]. The Register also said it had seen no in-the-wild exploitation of CVE-2026-110264 as of publication, but expected criminals to begin scanning for vulnerable instances soon ^[4].