GitLab released patches on October 21 for CVE-2026-110264, a CVSS 10.0 flaw that lets an unauthenticated remote attacker execute code on self-managed GitLab servers. The bug affects both Community and Enterprise Editions and, according to reporting on the advisory, exists in every release going back to version 7.0 from 2014. GitLab.com and GitLab Dedicated were fixed before disclosure; only self-managed operators need to act.

What happened

The flaw is an integer overflow in regular-expression compilation. Under specific conditions, attacker-controlled input reaches the vulnerable regex path and corrupts memory in the Rails application process, which leads to code execution without any authentication. GitLab’s advisory withholds the full exploit conditions. Several third-party write-ups attribute the root cause to the Onigmo regex engine bundled with Ruby, and one claims the trigger is a crafted Org-mode file rendered by GitLab. We could not confirm either detail against a primary source, so treat both as unverified.

At the time of writing, GitLab reports no confirmed exploitation and the CVE is not in CISA’s Known Exploited Vulnerabilities catalog (as of October 22). That window is short. GitLab’s earlier maximum-severity bugs this year saw in-the-wild probing within hours of patch publication, and a regex-engine integer overflow in a 12-year-old code path is a natural target for patch diffing.

Affected and fixed versions

All self-managed GitLab CE/EE releases back to 7.0 are affected. Fixed releases:

  • 19.5.1
  • 19.4.3
  • 19.3.6
  • Backports: 19.2.9, 19.1.9, 19.0.10, 18.11.13

Reports indicate that instances updated in GitLab’s October 12 patch cycle are not protected against this bug and need the new releases. The update also ships database migrations, which can lengthen the upgrade and affects how you plan the maintenance window, particularly for multi-node and zero-downtime upgrade paths.

Impact

GitLab servers are high-value targets. A code-execution foothold on the Rails host exposes repository contents, CI/CD variables and masked secrets, deploy keys, runner registration tokens, OAuth and personal access tokens, and the ability to alter pipeline definitions that run on downstream runners. For many organizations a compromised GitLab instance is a direct path into the build pipeline and from there into production and package registries. The unauthenticated nature of the bug means internet-exposed instances are the immediate priority, but internal instances are reachable by any attacker who gains a network foothold.

Mitigation

  1. Upgrade now to the fixed release for your branch. Do not rely on the October 12 patch level.
  2. Restrict exposure until patched: place the instance behind a VPN or IP allowlist, or block external access at the reverse proxy and load balancer.
  3. Hunt for compromise on instances that were internet-reachable: unexpected child processes of Puma or Sidekiq, new admin users, new personal access tokens or deploy keys, modified CI/CD variables, altered .gitlab-ci.yml files, and unfamiliar runner registrations.
  4. Rotate secrets stored in GitLab if you find any sign of compromise: CI/CD variables, runner tokens, deploy keys, and integration credentials.
  5. Watch for exploitation reports and the CISA KEV catalog; GitLab’s advisory is the authoritative source for any workaround or newly published detail.

References