# GitLab's 10.0 Org-mode flaw reaches back to 2014, and only 18.11 and newer get a patch

CVE-2026-110264 can let an unauthenticated attacker run code on self-managed GitLab CE and EE from version 7.0 on. Upgrade to a fixed release, then check your logs.

By Synt World. Published: 2026-10-22T08:25:48+00:00. Updated: 2026-10-22T08:25:48+00:00.

## At a glance

- **Bottom line:** If you run self-managed GitLab, CE or EE, upgrade now to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. Anything older than 18.11 has no patch on its own branch and has to climb the upgrade path.
- **Affected:** GitLab CE and EE from 7.0 (June 2014) up to the fixed releases, all deployment types. GitLab says GitLab.com is already patched and GitLab Dedicated tenants need no action.
- **Exploitation:** Not in CISA's Known Exploited Vulnerabilities catalog as of October 22, 2026, and GitLab's advisory makes no exploitation claim. GitLab has published detection rules for exploitation attempts. For the related bug GitLab fixed on October 12, Rapid7 published a proof of concept the next day.

## What GitLab fixed on October 21

On October 21, 2026, GitLab shipped a critical patch release for Community Edition and Enterprise Edition: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. The headline fix is CVE-2026-110264. In GitLab's words, an integer overflow when compiling a specially crafted regular expression could have allowed an unauthenticated user to execute arbitrary code on the GitLab server. GitLab credits the researcher joaxcar, who reported it through HackerOne. The same researcher reported the CI/CD regex bugs GitLab fixed on September 23 and October 12.

The advisory says little. GitLab's detection guidance, published with it, says more. The vulnerable path is the rendering of Org-mode (.org) files, which runs through the org-ruby gem and Onigmo, the regular-expression engine inside Ruby. A successful attack runs code as the git user. GitLab spells out what that exposes: the instance secrets in gitlab-secrets.json, every CI/CD variable, runner tokens, access tokens, and read and write access to every repository on the instance.

The same upgrade fixes eleven more issues, including two rated High: CVE-2026-15723 (8.2), an account takeover when OmniAuth SAML and LDAP auto-linking are both on, and CVE-2026-112212 (7.5), OAuth/OIDC discovery cache poisoning.

## Checking the headline: 10 out of 10, every version since 2014

The 10.0 is GitLab's own score, assigned as the CVE Numbering Authority for its product. The CVE.org record carries the CVSS 3.1 vector: network, low complexity, no privileges, no user interaction, changed scope, high impact across the board. The arithmetic is right. NVD had not scored it by October 22; its record, marked Received, shows only GitLab's score and CWE-190 (integer overflow).

Our reading, not an official correction: GitLab's own detection guidance describes the attack as noisy, with most attempts failing to land cleanly. That sits awkwardly with low attack complexity. Rate complexity high and the same vector scores 9.0. Critical either way; it changes nothing about what you do tonight.

"Every version since 2014" holds up. The record lists every version from 7.0 onward as affected, and GitLab tagged 7.0.0 on June 20, 2014. Strictly, that is every version since mid-2014: releases before 7.0 are outside the stated range. The headline misses the part that matters more: fixes exist only for 18.11 and newer. On 18.10 or older there is no patch for your branch, so you have to upgrade across releases.

That reach sets it apart. The CI/CD regex bugs of September 23 and October 12 only reached back to 19.2, released in July. If you skipped the October 12 advisory because you run 18.x or older, this one is yours.

![Bar chart: years between the first affected GitLab release and the fix, by CVE-2026 number. 85706: 0.7. 87719: 1.1. 89078: 0.2. 93577: 0.2. 97229: 0.2. 110264: 12.3.](/assets/insights/gitlab-org-mode-remote-code-execution-1.svg)

The six GitLab CE/EE bugs scored 9.9 or 10.0 and fixed between September 10 and October 21, 2026, by CVE-2026 number. Each bar runs from the first affected release to GitLab's fix date.

## What an attacker needs

GitLab's advisory says "under certain conditions" and stops there. Its detection guidance names the condition for the unauthenticated path: a public project that holds a crafted .org file. GitLab doesn't say who has to put the file there.

On many instances that is a low bar. GitLab's documentation says anyone who visits a self-managed instance can create an account by default, and unless an administrator restricts the Public visibility level, users can create public projects. Rapid7 made the same point about the October 12 bug: self-registration plus public projects removes the authentication barrier. GitLab hasn't said whether that applies here. We assume it does.

Closed sign-up and no public projects don't make you safe. GitLab's guidance describes the attacker as anyone who can make GitLab render a .org file. On our reading, any account that can push a file reaches the same code: a contractor, an old account nobody disabled, a phished password. Closing the public path narrows exposure. Only the upgrade closes the bug.

## Is anyone exploiting it?

As of October 22, 2026, CVE-2026-110264 is not in CISA's Known Exploited Vulnerabilities catalog (October 21 edition). GitLab's advisory makes no claim either way, but ships two detection rules for exploitation attempts. SecurityOnline reports no confirmed exploitation in the wild. We searched GitHub on October 22 and found no public exploit code for this CVE.

Don't count on that lasting. For the October 12 bug, Rapid7 says it reproduced code execution on an official GitLab image, and it published a proof of concept on GitHub the next day. GitLab's detection pages explain this bug's mechanism in far more depth than its advisory. Our judgement, not a reported fact: a working exploit is not far off. And attackers already target GitLab this autumn. CISA listed CVE-2026-85706, an unauthenticated file read GitLab fixed on September 10, as exploited the next day.

- 2026-09-10: GitLab fixes CVE-2026-85706, unauthenticated file read, 10.0 (GitLab).
- 2026-09-11: CISA adds CVE-2026-85706 to the KEV catalog (CISA).
- 2026-09-23: GitLab fixes CVE-2026-89078 and CVE-2026-93577, authenticated CI/CD regex code execution, both 9.9 (GitLab).
- 2026-10-12: GitLab fixes CVE-2026-97229, unauthenticated CI/CD regex code execution in 19.2 and later, 10.0 (GitLab).
- 2026-10-13: Rapid7 publishes its analysis of CVE-2026-97229 (Rapid7). CVE-2026-110264 is reserved (CVE.org).
- 2026-10-21: GitLab fixes CVE-2026-110264 in seven release lines, back to 18.11 (GitLab).
- 2026-10-22: CVE record published; NVD status Received; not in KEV (CVE.org, NVD, CISA).

## Find your version and upgrade

Start by finding out what you run. Any signed-in user can see the version at the top of Help > Help. On the server, or through the API:

````
# Linux package (Omnibus)
sudo gitlab-rake gitlab:env:info | grep -A2 'GitLab information'

# Self-compiled installation
sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production

# Any installation, with a personal access token
curl --header "PRIVATE-TOKEN: $TOKEN" "$GITLAB_URL/api/v4/version"
````

- On a branch GitLab still patched, take that branch's fixed release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13 (GitLab).
- Older than 18.11: plan the path. GitLab's required 18.x stops are 18.2, 18.5, 18.8 and 18.11, and 18.11.13 is both a required stop and a fixed release, so land there first. GitLab Support's Upgrade Path tool lists your stops. Let background migrations finish at each one (GitLab).
- Single-node instances will see downtime: 19.4.3 and 19.3.6 carry database migrations that must finish before GitLab starts. Multi-node instances can upgrade without downtime (GitLab).
- Self-compiled installations: the release's fix list includes patches to the Ruby GitLab bundles in its packages and images. On your own Ruby, ask GitLab whether the application upgrade alone covers you.
- GitLab.com: nothing to do. GitLab says it already runs the patched version. GitLab Dedicated: GitLab says tenants on 19.3.5-internal0, 19.4.2-internal0 or later already have the fixes.

## If you can't upgrade today

GitLab's release post lists no workaround. Its detection guidance offers two interim steps: reduce public visibility where you can, and make sure the right logs are collected. As an administrator, that means:

- Restrict the Public visibility level under Admin > Settings > General > Visibility and access controls. Only administrators can then create public projects. Existing public projects stay public, so review them and make the ones that needn't be public internal or private (GitLab docs).
- Turn off new account creation under Admin > Settings > General > New user account restrictions if you don't expect strangers to register. GitLab's docs recommend this for public-facing instances anyway.
- Make sure your log pipeline collects exceptions_json.log and puma_stderr.log. GitLab warns that native crash reports are often not shipped by default.
- Our suggestion beyond GitLab's: if the instance doesn't need to face the internet, put it behind a VPN or an IP allowlist until it's patched.

None of this stops a signed-in user. It buys hours, not a fix.

## What to check if you were exposed

GitLab published two detection rules in Sigma format. Deploy them as written. In plain terms they look for:

- Bursts of render timeouts on .org files from one client in exceptions_json.log, logged as a Timeout::Error from the OtherMarkup renderer. GitLab's rule fires at five or more from one client within 30 minutes.
- Native Ruby crash reports, marked [BUG], whose backtrace mentions org-ruby or Onigmo, in puma_stderr.log. GitLab treats a hit as attempted remote code execution.

If you collect the Workhorse log, GitLab also points to 502 errors on requests for .org files. Without a SIEM, GitLab's raw queries for the first two, adapted here for rotated logs on a Linux package install:

````
# Org-mode render timeouts, counted per client
zgrep -h '"exception.class":"Timeout::Error"' /var/log/gitlab/gitlab-rails/exceptions_json.log* \
  | grep '"extra.class_name":"OtherMarkup"' \
  | grep -E '"extra.file_name":"[^"]*\.org"' \
  | grep -o '"meta.client_id":"[^"]*"' | sort | uniq -c | sort -rn

# Native [BUG] crash reports that reference org-ruby or Onigmo frames
zgrep -h -B1 -A20 '\[BUG\]' /var/log/gitlab/puma/puma_stderr.log* \
  | grep -E 'org-ruby|regexp_matcher\.rb|match_at|onig_search_gpos|onig_compile|compile_tree|compile_length_tree|rb_str_sub_bang'
````

GitLab is blunt about the limits. A successful exploit can be quiet and crash nothing, so a clean result doesn't clear you, and a quiet spell after a burst can mean success rather than surrender. Hunt for success directly, as GitLab advises: files owned by git in /tmp, unexpected child processes of Puma or Sidekiq, outbound connections from the host, and changed crontabs or SSH keys for the git user.

Then the application side, from October 21 back as far as your logs go. In audit events, look for new administrators, new access or impersonation tokens, new SSH or deploy keys, new runners and changed instance settings. GitLab's docs put the instance-wide audit view in Premium and Ultimate; on Free or CE you have the logs. Code on the server can bypass the web app, so an empty audit log proves little.

If you find signs of code execution, GitLab says to treat the instance as compromised. Preserve logs and full crash reports first. Then rotate the secrets in gitlab-secrets.json, all CI/CD variables, runner tokens and access tokens. Many of those credentials open cloud accounts, registries and deploy targets, so rotate them there too.

One more check: if your instance ran 18.7 or later and missed the September fixes, CVE-2026-85706 applies too, and that one is exploited. GitLab's release post for it links separate detection rules.

## Why a file renderer deserves your evening

Hardly anyone's threat model includes the Org-mode renderer. Most GitLab users never touch it, yet GitLab says this bug spans twelve years of releases. A self-hosted platform's attack surface is every parser it ships, not the features you use. Since September 10, GitLab has fixed seven bugs scored 9.9 or 10.0, one of them in its AI Gateway, and attackers have already exploited one. A patch cycle measured in weeks is too slow for this autumn. Patch, check, and if anything looks off, assume the secrets are gone.

## Sources

- [GitLab: GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 (October 21, 2026)](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/)
- [CVE.org: CVE-2026-110264](https://www.cve.org/CVERecord?id=CVE-2026-110264)
- [NVD: CVE-2026-110264](https://nvd.nist.gov/vuln/detail/CVE-2026-110264)
- [CISA: Known Exploited Vulnerabilities Catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog)
- [CISA: Known Exploited Vulnerabilities Catalog, CVE-2026-85706](https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-85706)
- [GitLab Security: Onigmo native worker crash (detection)](https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/onigmo_native_worker_crash.md?ref_type=heads)
- [GitLab Security: Org mode render error burst (detection)](https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/org_mode_render_error_burst.md?ref_type=heads)
- [GitLab: GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8 (October 12, 2026)](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/)
- [GitLab: GitLab Critical Patch Release: 19.4.1, 19.3.3, 19.2.7 (September 23, 2026)](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-1-released/)
- [GitLab: GitLab Critical Patch Release: 19.3.2, 19.2.6, 19.1.8 (September 10, 2026)](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-3-2-released/)
- [GitLab: GitLab AI Gateway Critical Patch Release: 19.2.4, 19.3.2, and 19.4.1 (October 2, 2026)](https://docs.gitlab.com/releases/patches/other-patches/patch-release-gitlab-ai-gateway-19-4-1-released/)
- [Rapid7: CVE-2026-97229: Critical Unauthenticated Remote Code Execution in GitLab](https://www.rapid7.com/blog/post/etr-cve-2026-97229-critical-unauthenticated-remote-code-execution-in-gitlab)
- [GitLab: GitLab FOSS tag v7.0.0](https://gitlab.com/gitlab-org/gitlab-foss/-/tags/v7.0.0)
- [GitLab Docs: GitLab 19.2 release notes](https://docs.gitlab.com/releases/19/gitlab-19-2-released/)
- [GitLab Docs: GitLab 18.3 release notes](https://docs.gitlab.com/releases/18/gitlab-18-3-released/)
- [GitLab Docs: GitLab 18.7 release notes](https://docs.gitlab.com/releases/18/gitlab-18-7-released/)
- [GitLab Docs: Find the GitLab version](https://docs.gitlab.com/user/version/)
- [GitLab Docs: Maintenance Rake tasks](https://docs.gitlab.com/administration/raketasks/maintenance/)
- [GitLab Docs: Metadata API](https://docs.gitlab.com/api/version/)
- [GitLab Docs: Plan your upgrade path](https://docs.gitlab.com/update/upgrade_paths/)
- [GitLab Support: Upgrade Path tool](https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/)
- [GitLab Docs: Control access and visibility](https://docs.gitlab.com/administration/settings/visibility_and_access_controls/)
- [GitLab Docs: New user account restrictions](https://docs.gitlab.com/administration/settings/sign_up_restrictions/)
- [GitLab Docs: Log system](https://docs.gitlab.com/administration/logs/)
- [GitLab Docs: Audit events administration](https://docs.gitlab.com/administration/compliance/audit_event_reports/)
- [SecurityOnline: GitLab Critical Patch Release Fixes 10.0 CVSS Remote Code Execution Flaw and 11 Other Bugs](https://securityonline.info/gitlab-critical-patch-release-cve-2026-110264/)
- [National Vulnerability Database](https://nvd.nist.gov): This product uses the NVD API but is not endorsed or certified by the NVD.