GitLab has released an emergency security update for a maximum-severity flaw that can let an unauthenticated attacker run code on a self-managed GitLab server. The vulnerability, tracked as CVE-2026-110264, affects Community Edition and Enterprise Edition releases going back to GitLab 7.0.
The October 21 patch fixes an integer overflow triggered while GitLab compiles a specially crafted regular expression. GitLab rates the bug 10.0 on the CVSS scale and says all deployment types are affected. GitLab.com is already patched, and sufficiently recent GitLab Dedicated tenants do not need to act. The urgent work falls on organizations that operate GitLab themselves.
GitLab also published two detection rules for the flaw. Independent internet measurements from Censys found roughly 82,000 hosts and 208,000 web properties running GitLab on the day of disclosure. Censys estimated that more than half of exposed servers used a release line too old to receive a direct patch, which means many operators cannot solve this with a one-step package update.
Which GitLab versions fix CVE-2026-110264?
Administrators should move to the fixed release for their current supported branch:
| Current branch | First fixed release |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 | 19.2.9 |
| 19.1 | 19.1.9 |
| 19.0 | 19.0.10 |
| 18.11 | 18.11.13 |
Every GitLab release from 7.0 through 18.11.12 is vulnerable, along with 19.0.0 through 19.0.9, 19.1.0 through 19.1.8, 19.2.0 through 19.2.8, 19.3.0 through 19.3.5, 19.4.0 through 19.4.2, and 19.5.0.
There is an easy trap here: the October 12 security releases, including 19.4.2, 19.3.5 and 19.2.8, do not fix CVE-2026-110264. Those builds addressed a different regular-expression flaw. A server patched earlier in October still needs the October 21 update.
Why this GitLab RCE is unusually dangerous
GitLab’s public advisory describes an integer overflow in its regular-expression compiler. Its accompanying detection material places the reachable path in the renderer for Org-mode .org files: a value in a #+TODO: line is passed into a regular expression. An attacker does not need a GitLab account, but the instance must expose at least one public project that can hold or render the malicious Org-mode content.
Successful code execution runs with the GitLab service account’s privileges. That position can expose far more than the server itself. A GitLab instance may hold private source code, CI/CD variables, deploy keys, runner tokens, personal access tokens, container-registry credentials and infrastructure definitions. Attackers could steal those secrets, alter repositories or pipelines, or use the server as a route into build and production systems.
No in-the-wild exploitation had been confirmed in public reporting through October 24, and CVE-2026-110264 was not in CISA’s Known Exploited Vulnerabilities catalog at that point. That is not a reason to delay: GitLab gave the flaw the highest possible severity score, released detection guidance alongside the patch, and has not published a configuration workaround.
Check your GitLab version without exposing more information
On a Linux package installation, an administrator can retrieve the installed version and environment information locally:
sudo gitlab-rake gitlab:env:infoFor a Docker deployment, run the same task inside the GitLab container, replacing the container name if necessary:
docker exec gitlab gitlab-rake gitlab:env:infoThe version is also visible to signed-in administrators in the GitLab interface. Avoid relying on a public version-detection scanner alone: proxies, custom headers and hidden sign-in pages can make external inventory incomplete. Check package records, container tags, Helm releases and every disaster-recovery or staging instance as well as the primary server.
Patch in the right order
- Inventory every self-managed instance. Include test systems, warm standbys, migration targets and GitLab nodes reachable only through a VPN. An overlooked clone can contain the same repositories and secrets as production.
- Preserve useful logs before maintenance. Retain GitLab application logs, reverse-proxy logs, system journals, process telemetry and authentication records. Fast-moving logs may rotate while the upgrade is underway.
- Use the fixed build for the branch. Follow GitLab’s package, Docker or Helm instructions rather than changing only the bundled Ruby component. The supported remediation is a patched GitLab release.
- Respect required upgrade stops. Older installations cannot jump directly to 18.11.13 or 19.5.1. GitLab requires staged upgrades, with background migrations completed at each stop. Its supported path uses the latest patch release at required
x.2,x.5,x.8andx.11stops for newer major versions. - Plan for migrations and downtime. GitLab warns that 19.3.6 and 19.4.3 include regular database migrations; 19.4.3 also includes post-deploy migrations. Single-node instances will be unavailable while required migrations complete. Properly designed multi-node deployments can use GitLab’s zero-downtime procedure.
- Verify the running version after restart. Confirm the application reports the patched build, check that database migrations completed, and test repository access, CI jobs, the registry and authentication integrations.
GitLab’s upgrade-path documentation lists the required stops, and its October 21 security release is the authoritative source for fixed versions.
What to hunt for before declaring the incident closed
Patching blocks the vulnerable path, but it does not remove persistence or invalidate stolen credentials. GitLab released detections for two observable patterns: crashes of the Onigmo native worker and bursts of Org-mode rendering errors. The exploit path can be noisy and unreliable, so repeated failures may be as useful as a single successful request.
Review the exposure window for:
- unusual requests that render
.orgfiles, especially activity involving public projects and unfamiliar#+TODO:content; - Onigmo or native-worker crashes and clusters of Org-mode render failures;
- unexpected child processes launched by Puma or other GitLab application processes;
- new or modified files owned by the
gituser in/tmpor other writable directories; - changes to the
gituser’s crontab, authorized SSH keys or shell configuration; - unexplained outbound network connections, new CI jobs, modified pipelines, added deploy keys or recently created access tokens.
A clean crash search is not proof that exploitation failed. Successful code execution may not crash the worker, and an attacker can act through legitimate GitLab credentials after stealing them. Correlate GitLab events with endpoint, network, identity and cloud logs.
If the evidence suggests code execution, isolate the instance and treat its secrets as exposed. Rotate CI/CD variables, deploy credentials, access and runner tokens, registry credentials, webhooks, OAuth secrets and downstream cloud keys. Review repository and pipeline history for unauthorized changes, rebuild runners or adjacent hosts where trust is uncertain, and follow GitLab’s documented secret-rotation procedure carefully; changing instance secrets without a plan can invalidate encrypted data and active sessions.
The practical decision
Organizations already on a supported 18.11 or 19.x branch should install the fixed patch immediately. Operators on older branches face a longer upgrade, but leaving the service exposed while planning that migration is the worst option. Restrict network access, remove anonymous reachability to public projects where operationally possible, preserve evidence and start the supported upgrade path.
Censys’ exposure analysis shows why the age of the flaw matters: the vulnerable population includes years of self-managed installations, many far outside a directly patched branch. The absence of a confirmed attack report only describes what defenders have publicly observed so far. It does not shrink the blast radius of a compromised source-code and CI/CD platform.
