GitLab CVE-2026-110264: critical unauthenticated RCE needs urgent patching

GitLab has released critical fixes for CVE-2026-110264, a vulnerability that could allow remote code execution on a GitLab server under certain conditions. The attack requires no authentication or user interaction. GitLab rated it 10.0 under CVSS 3.1 and recommends that every affected self-managed installation upgrade immediately.

The issue involves an integer overflow while compiling a specially crafted regular expression. For an organisation, the weakness class matters less than GitLab’s role: the server commonly holds source code, CI/CD secrets, artifacts, deployment keys and routes into production. Code execution on this platform can therefore become the opening stage of a software-delivery compromise.

Which versions are affected

GitLab lists these CE and EE ranges:

• 7.0 through versions before 18.11.13;
• 19.0 before 19.0.10;
• 19.1 before 19.1.9;
• 19.2 before 19.2.9;
• 19.3 before 19.3.6;
• 19.4 before 19.4.3;
• 19.5 before 19.5.1.

Fixes are available in 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1. The vendor made additional backports beyond its standard patch branches, which gives organisations a faster response path when an immediate major-line upgrade is impractical.

GitLab.com is already patched. GitLab also says Dedicated tenants running 19.3.5-internal0 and 19.4.2-internal0 or later already include the fixes and require no action. The urgent operational task primarily belongs to GitLab Self-Managed owners.

Why this issue receives top priority

The vendor’s CVSS vector describes a network attack with low complexity, no required privileges and no user interaction. Potential confidentiality, integrity and availability impact is high.

A 10.0 score does not mean every instance has been attacked. At publication time, the vendor had not confirmed widespread exploitation. Organisations should not wait for that evidence: an internet-facing GitLab instance that controls source and delivery processes has high business impact, while a fix is already available.

Breachroad’s conclusion: public instances and systems connected to production runners belong at the front of the queue. An internal instance is not automatically safe merely because it lacks a public address. VPN access, partner accounts, employee workstations and other compromised systems can still provide an attack path.

An action plan for today

1. Confirm service type and version

Separate GitLab.com, Dedicated and Self-Managed. For your own installations, retrieve the version from a reliable source and check every node, container and disaster-recovery environment. An inventory limited to the main hostname may miss staging, a standby node or a legacy instance serving one team.

2. Upgrade to a fixed release

Select the patched release appropriate to your branch and GitLab’s documentation. Confirm backups, migration requirements and a recovery plan before the change. Do not defer the security patch solely to bundle it with a larger functional upgrade; the critical fix has its own priority.

3. Reduce exposure until the change completes

If the upgrade requires a maintenance window, restrict access through a reverse proxy, VPN, allowlist or network control where that will not interrupt essential operations. This is a temporary mitigation, not a substitute for the fix.

4. Use the vendor’s detections

GitLab published two detections for self-managed instances: Onigmo native worker crash and Org mode render error burst. A hit should trigger incident analysis. An absence of alerts is not proof of safety; detecting an attempt is different from guaranteeing that successful code execution will be visible.

5. Look for effects, not only the entry signal

Review new accounts and keys, role changes, runner configuration, webhooks, tokens, pipelines, protected branches and unusual administrative operations. If code execution is suspected, treat GitLab as potentially compromised: preserve logs, isolate the system, validate integrity and plan rotation of credentials available to the platform.

What leadership and service owners need to know

“GitLab has been upgraded” is not sufficient business closure. The service owner should be able to answer four questions:

1. How many instances were in the affected range, and which were externally reachable?
2. When did each receive the fix?
3. Do logs cover the full interval from disclosure to patching?
4. Was there evidence of attempted exploitation or compromise effects?

It is also worth checking whether runners hold persistent production credentials and whether one project’s secret works outside its intended scope. A critical developer-platform vulnerability often exposes earlier weaknesses in segmentation and secret management.

Preparing for the next critical CVE

Vulnerability management should connect vendor intelligence with asset inventory and business impact. A minimum standard includes an owner for every instance, automated version reporting, vendor advisory subscriptions, a defined critical-patch window and a rehearsed emergency process.

Logs also need to exist outside GitLab itself. If the platform is compromised, local records may be altered or deleted. A central SIEM, reverse-proxy logs and EDR telemetry provide independent evidence.

Source facts and Breachroad conclusions

GitLab confirms the RCE outcome, unauthenticated vector, 10.0 rating, affected ranges, fixed versions and availability of two detections. The vendor also confirms the state of GitLab.com and the identified Dedicated versions.

Exposure-based prioritisation, the impact-review scope and reporting questions are Breachroad recommendations. See our vulnerability management process and CI/CD pipeline security guide for more context. Developers, administrators and service owners can rehearse coordinated response through cybersecurity training for organisations, while an IT security audit can assess platform resilience.

Primary source: GitLab — Critical Patch Release 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13.