GitLab CVE-2026-110264: CVSS 10 RCE via Org-mode Files

What to do

1. Check your version (sudo gitlab-rake gitlab:env:info, or Admin area) and list every self-managed instance, including test and mirror servers.
2. Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13; on 18.10 or older, follow the upgrade path to at least 18.11.13.
3. Until patched, cut unauthenticated reach: disable open sign-up, make public projects internal or private, or put the instance behind VPN or SSO.
4. Run GitLab's two published detections against exceptions_json.log and puma_stderr.log, and scan repositories for oversized #+TODO: lines in .org files.
5. If you find signs of code execution, rotate gitlab-secrets.json secrets, CI/CD variables, runner tokens and access tokens.

How to check if you are affected or compromised

• Count Org-mode render timeouts per client: grep Timeout::Error /var/log/gitlab/gitlab-rails/exceptions_json.log | grep OtherMarkup | grep '\.org'. GitLab alerts on five or more from one client in 30 minutes.
• Search /var/log/gitlab/puma/puma_stderr.log for Ruby [BUG] crash reports that mention org-ruby (headline.rb) or Onigmo frames such as match_at or onig_search_gpos.
• Scan repositories for the payload: rg -l --glob '**/*.org' '^#\+(TODO|SEQ_TODO|TYP_TODO):.{500,}'.
• Look for editor preview requests (Projects::BlobController#preview) that pass a .org file_path for a non-.org file, and Workhorse 502s on .org blob URLs.

What happened#

On October 21, 2026, GitLab shipped a 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) for Community and Enterprise Edition. The headline fix is CVE-2026-110264, an integer overflow when compiling "a specially crafted regular expression." GitLab says it "could have allowed an unauthenticated user to execute arbitrary code on the GitLab server," under certain conditions, and scores it CVSS 3.1 10.0. The researcher joaxcar reported it through HackerOne.

The advisory is terse, but GitLab's own detection write-up explains the bug. GitLab renders .org files with the org-ruby gem. That gem places a raw keyword from a #+TODO: line straight into Regexp.new. A keyword with more than 32,767 repeats pushes a 16-bit counter in Ruby's Onigmo regex engine past its limit, which causes an out-of-bounds write. With heap grooming, that becomes a system() call as the git user. GitLab says the attack needs "no authentication," only one public project that can hold the .org payload.

The same researcher found a related CVSS 10 Onigmo flaw in CI regex rules, CVE-2026-97229. GitLab fixed it on October 12 in 19.4.2, 19.3.5 and 19.2.8 (The Hacker News). Servers patched for that bug are still exposed to this one. The October 21 release also fixes CVE-2026-15723 (8.2), an account takeover when OmniAuth SAML and LDAP auto-linking are both on, and CVE-2026-112212 (7.5), poisoning of cached OAuth/OIDC discovery documents.

Who is affected#

Every self-managed GitLab CE/EE install from 7.0 up to the fixed versions, which in practice means nearly every self-managed instance. Backports cover 19.0 through 19.2 and 18.11. Anything older than 18.11 has to upgrade across lines. GitLab.com and GitLab Dedicated are already patched. BleepingComputer cites Shadowserver tracking over 2,700 internet-exposed GitLab CE instances.

Do you really need to act?#

Yes, this week. Sooner if strangers can reach the instance. The unauthenticated path needs a public .org file that GitLab will render. The detection notes describe a second route through the web editor's preview, which a signed-in user can point at the Org renderer without committing anything. Risk therefore splits like this:

• Highest: internet-facing instances with public projects or open self-registration. Anyone can plant or render a payload.
• Medium: internal instances where many people hold accounts, such as contractors or a whole company.
• Lower: instances reachable only over VPN by a small trusted team.

No in-the-wild exploitation is reported, and the CVE is not in CISA KEV. GitLab calls the attack "a grind": noisy, with most attempts failing to land cleanly. That buys some time, but not much. GitLab's detection notes give away the trigger, and last month's CVSS 10 GitLab file-read bug, CVE-2026-85706, ended up in KEV.

What to do now#

1. Find every self-managed instance and its version: sudo gitlab-rake gitlab:env:info on Omnibus, or the Admin area.
2. Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. Single-node installs take downtime for migrations. Multi-node installs can use GitLab's zero-downtime procedure.
3. If you cannot upgrade today, reduce exposure: turn off open sign-up, make public projects internal or private, or move the instance behind VPN or SSO.
4. Turn on GitLab's two detections, "Org mode render error burst" and "Onigmo native worker crash," and make sure your log shipper collects exceptions_json.log and puma_stderr.log.

How to tell if you were hit#

GitLab's detections look for three things:

• bursts of Timeout::Error from the OtherMarkup renderer on .org files in exceptions_json.log (five or more from one client in 30 minutes)
• Ruby [BUG] crash reports in puma_stderr.log with org-ruby or Onigmo frames
• Workhorse 502s on .org blob routes

On the git side, scan for the payload: rg -l --glob '**/*.org' '^#\+(TODO|SEQ_TODO|TYP_TODO):.{500,}'. GitLab warns that a successful exploit can be quiet, so a lack of crashes proves nothing. If you find evidence of execution, treat the server as compromised. Rotate the secrets in gitlab-secrets.json, all CI/CD variables, runner tokens and access tokens.

Timeline#

• Oct 12, 2026 — GitLab fixes CVE-2026-97229 (Onigmo overflow via CI regex) in 19.4.2, 19.3.5 and 19.2.8.
• Oct 21, 2026 — GitLab releases 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, fixing CVE-2026-110264 and 11 other issues.
• Oct 22, 2026 — The CVE record is published. No exploitation is reported, and the CVE is not in CISA KEV.

Vulnerability records

• CVE-2026-110264 · An issue has been discovered in GitLab CE/EE affecting 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…

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. GitLab — Patch release 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 docs.gitlab.com
2. GitLab Security (TLDR) — Org mode render error burst detection gitlab.com
3. GitLab Security (TLDR) — Onigmo native worker crash detection gitlab.com
4. CVE record — CVE-2026-110264 cve.org

Coverage and analysis

1. BleepingComputer — GitLab warns of new max severity code execution vulnerability bleepingcomputer.com
2. The Hacker News — GitLab patches CVSS 10.0 flaw that could let unauthenticated users run server code (CVE-2026-97229) thehackernews.com