GitLab CVE-2026-110264: CVSS 10 unauthenticated RCE through a rendered .org file

GitLab shipped a critical patch release on October 21 for CVE-2026-110264, rated CVSS 10.0: under certain conditions an unauthenticated user can execute arbitrary code on a self-managed GitLab server, through an integer overflow when GitLab compiles a crafted regular expression. GitLab's own detection notes name the path: a crafted Org-mode (.org) file in any public project, rendered by the server. The affected range starts at GitLab 7.0, and the instances patched for GitLab's October 12 critical release are still inside it.

Developing story — first published 13:46 CEST (11:46 UTC), October 22, 2026. Updated as the vendor and CISA publish more.

At a glance

CVE	CVE-2026-110264
Product / affected versions	GitLab CE/EE self-managed · all versions from 7.0 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
Fixed in	19.5.1 · 19.4.3 · 19.3.6 · backports 19.2.9 · 19.1.9 · 19.0.10 · 18.11.13 (released October 21, 2026)
CVSS	10.0 Critical · CVSS 3.1 · AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H · scored by GitLab (CNA); NVD has not scored it yet
Exploited in the wild	Not reported by GitLab; no CISA or national-CERT exploitation report found
CISA KEV	Not listed (catalog version 2026.10.21)
Official advisory	GitLab Critical Patch Release 19.5.1

What GitLab fixed, and why "since 7.0" is real

The release post bundles 12 security fixes; CVE-2026-110264 is the only critical one, reported through HackerOne by the researcher joaxcar. The affected range in both the advisory and the CVE record starts at GitLab 7.0, so this is not a press exaggeration: every self-managed release line still in use is in scope, including installs far older than anything GitLab still supports. GitLab.com and GitLab Dedicated are already patched. GitLab publishes no workaround.

The mechanism comes from GitLab's own security detection write-ups, not from the advisory text. In the Org-mode render detection, GitLab explains that .org files are rendered with the org-ruby gem (0.9.12), which takes a custom keyword from a #+TODO: line and interpolates it unescaped into Regexp.new. A keyword with more than 32,767 repeats pushes a repeat ID in Ruby's Onigmo regex engine past the signed 16-bit limit; the ID wraps negative and the matcher writes out of bounds. With heap grooming, GitLab says, that becomes a system() call as the git user, and the attack needs only one public project that can hold the .org payload.

A file in a repository is data until the server renders it. On GitLab, rendering happens for anyone who can open the project page.

Why the October 12 patch does not cover it

This is the same regex engine as CVE-2026-97229, the CI/CD rules:regexp overflow GitLab fixed on October 12 in 19.4.2, 19.3.5 and 19.2.8. GitLab's Onigmo crash detection treats them as one family with two entry points: the CI path overflows at compile time, the Org-mode path writes out of bounds at match time. Those October 12 versions are below the new fixed versions, so a team that patched ten days ago is still exposed and has to upgrade again.

The precedent worth remembering is CVE-2021-22205: GitLab passed uploaded images to a file parser without validating them, the result was unauthenticated command execution, and CISA added it to KEV in November 2021. Server-side rendering of attacker-supplied content is the recurring weak spot on this platform. More GitLab coverage, plus every GitLab CVE in the CISA catalog, is on our GitLab vulnerability page.

Who is exposed

• Internet-facing self-managed instances where anyone can see at least one public project, or where open sign-up lets anyone create one. That is the precondition GitLab describes.
• Internal instances are not safe by default: anyone with an account, or anyone who reaches a public project from a compromised workstation, sits on the same path.
• Installs on 18.10 or older have no fixed release of their own and must follow GitLab's upgrade path to 18.11.13 or later.
• Source installs running a system Ruby are not covered by the advisory, which gives no instructions for them.

What a successful attacker reaches, per GitLab: gitlab-secrets.json, every CI/CD variable, runner tokens and access tokens, and read and write access to every repository on the instance.

Remediation

1. Am I affected? Check the running version under Admin → Overview → Dashboard, or on an Omnibus host with sudo gitlab-rake gitlab:env:info. Anything below the fixed version of its branch is affected, including 19.4.2, 19.3.5 and 19.2.8.

2. Patch — exact fixed versions. Upgrade to 19.5.1, 19.4.3 or 19.3.6, or to the backports 19.2.9, 19.1.9, 19.0.10 or 18.11.13. Single-node instances go down while migrations run; multi-node instances can use GitLab's zero-downtime procedure. Start with the instances reachable from the internet.

3. Can't patch now? Compensating controls. GitLab gives no workaround and no setting disables Org rendering on its own, so these only shrink the exposure:

• Take the instance off the internet (VPN or IP allowlist in front of it) until it is patched.
• Close the precondition GitLab names: under Admin → Settings → General → Visibility and access controls, restrict the Public visibility level, and turn off sign-up under Sign-up restrictions. Authenticated users can still reach the renderer, so this is a delay, not a fix.

4. Hunt for compromise. GitLab published the indicators; use them as written:

• exceptions_json.log (Omnibus: /var/log/gitlab/gitlab-rails/exceptions_json.log): a burst of Timeout::Error with extra.class_name = OtherMarkup and an .org file in extra.file_name. GitLab's rule fires on five or more from one client within 30 minutes.
• Workhorse access log: HTTP 502 on the blob route of an .org file, the request that crashed a worker and never reached the Rails logs.
• puma_stderr.log (/var/log/gitlab/puma/puma_stderr.log): native [BUG] crash reports with org-ruby headline.rb or Onigmo frames such as match_at and onig_search_gpos.
• In the repositories: .org files with an oversized #+TODO:, #+SEQ_TODO: or #+TYP_TODO: line, which is the payload itself.

GitLab is explicit that a successful exploit is quiet and does not reliably crash: the absence of these signals does not clear an instance. MITRE ATT&CK: T1190 (Exploit Public-Facing Application), T1059.004 (Unix shell), T1552.001 (credentials in files), T1213.003 (data from code repositories).

5. Eradicate + verify. If any signal fires, treat the host as compromised: rebuild it from a known-good image instead of patching in place, then rotate what the git user could read: personal, project and group access tokens, runner tokens, CI/CD variables, deploy keys and OAuth application secrets. Plan the gitlab-secrets.json values separately, because some of them encrypt data in the database. Confirm the fixed version on every node afterwards, not only the one that alerted.

What is not known yet

• Whether anyone is exploiting it. GitLab does not say; it is not in KEV. A GitHub repository published as a CVE-2026-110264 exploit states in its own README that it implements the earlier CVE-2026-97229 chain.
• NVD's own score; the 10.0 is GitLab's.
• Whether the web editor preview, which GitLab's secondary rule watches, gives a second unauthenticated route.

Singapore's CSA issued an alert on October 22 telling administrators to patch immediately. If CISA lists it with total system control, BOD 26-04 would most likely put federal agencies on the shortest clock; we explain the tiers in our BOD 26-04 guide.

Testing your own GitLab, not the advisory

A version check tells you that your instance is in the range. It does not tell you whether an unauthenticated user can actually reach the Org renderer on your configuration: whether public projects are visible, whether sign-up is open, which nodes and mirrors sit behind which network path. Zero Hunt answers that as an attacker would: its autonomous AI red team identifies the exact GitLab version from outside, maps what an unauthenticated user can see, and its exploit forge iterates a proof-of-concept against that specific deployment until it demonstrably works. It runs black-box by default, on an on-premise appliance with private AI, and a human approves every exploitation step. The way to compare it with other tools is our guide to automated penetration testing.

The fix plan then comes from the Remediation Advisor: this CVE first if the proof landed, the exact upgrade and its rollback, the compensating control for the nodes that cannot be patched today, and a re-test with the same proof once the upgrade is in. Every step is signed at write time in a hash-chained evidence record, so "patched" is something you can show, not just a version string.