On 21 October 2026 GitLab fixed CVE-2026-110264, a CVSS 10.0 flaw that lets an unauthenticated attacker run code on a self-managed GitLab server. It affects every release since 7.0, including instances patched nine days earlier for a similar bug. Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. GitLab.com and Dedicated are already fixed.
Reflects what was publicly known on the last updated date. Every fact links to a primary source at the end of the page.
If you host GitLab yourself, yes.
You run self-managed GitLab
Linux package, Docker, Helm, source. CE or EE.
Upgrade today. Every version from 7.0 is affected. Fixed versions
You patched on 12 October
Running 19.4.2, 19.3.5 or 19.2.8
Still vulnerable. Those releases fixed a different regex bug. Upgrade again to 19.4.3, 19.3.6 or 19.2.9.
Your instance has public projects or open sign-up
Anonymous visitors can view, or anyone can register
The attack needs a public project to hold its payload. Upgrade these first and run the checks in Detect attempts.
You use OmniAuth SAML with LDAP auto-linking
Both enabled
A high-severity account takeover is fixed in the same release. CVE-2026-15723
You use GitLab.com or GitLab Dedicated
GitLab-managed
No action. GitLab has already applied the fix.
The upgrade is the fix. GitLab’s advisory lists no workaround.
Check the version you actually run
# Linux package or Docker (run inside the container for Docker)
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
# Helm: the image running the Webservice pods is what counts, not the chart
kubectl get pods -n <namespace> -l app=webservice \
-o jsonpath='{.items[*].spec.containers[?(@.name=="webservice")].image}'
# Any install, from outside (needs a personal access token)
curl -s -H "PRIVATE-TOKEN: <token>" https://gitlab.example.com/api/v4/versionUpgrade, internet-facing instances first
Look back for attempts before the upgrade
Rotate secrets if anything turns up
Any later release in the same line also contains the fix.
| If you run | Upgrade to | Notes |
|---|---|---|
| 19.5 | 19.5.1 | No migrations listed |
| 19.4 | 19.4.3 | Regular and post-deploy migrations |
| 19.3 | 19.3.6 | Regular migrations |
| 19.2 | 19.2.9 | Backport, critical fix only |
| 19.1 | 19.1.9 | Backport, critical fix only |
| 19.0 | 19.0.10 | Backport, critical fix only |
| 7.0 to 18.11 | 18.11.13 | Only fix for anything older than 19.0 |
GitLab normally patches only the latest three monthly releases. The four backports show how seriously it rates this bug. If you are on anything older than 18.11, use the Upgrade Path tool to find the required stops on the way to 18.11.13 or later.
GitLab's advisory says only 'under certain conditions'. Its security team's detection notes fill in the rest.
.org files with the org-ruby gem. The gem escapes the keywords on the file’s #+TODO: line once, then passes the raw keyword into a second regular expression.git user, which can read the instance’s secrets and every repository.These checks come from GitLab’s own detection rules. Paths are for the Linux package; see the GitLab log docs for Helm and source installs.
The attack is noisy. Most attempts push the renderer past its time limit and log a Timeout::Error. A normal reader renders an .org file once; an attacker renders it many times in a burst.
# Org-mode render timeouts per client. GitLab's rule fires on five or more
# from one client within 30 minutes, so check the timestamps of any high count.
# zgrep also reads rotated .gz logs.
EXC=/var/log/gitlab/gitlab-rails/exceptions_json.log
zgrep '"exception.class":"Timeout::Error"' "$EXC"* \
| grep '"extra.class_name":"OtherMarkup"' | grep -E '"extra.file_name":"[^"]*\.org"' \
| grep -o '"meta.client_id":"[^"]*"' | sort | uniq -c | sort -rnSigned-in attackers can also reach the renderer through the editor preview by naming a .org file while editing a different one. GitLab says legitimate traffic rarely does this.
# Editor previews that force the Org renderer onto a non-Org file. Any hit is notable.
PROD=/var/log/gitlab/gitlab-rails/production_json.log
zgrep 'Projects::BlobController#preview' "$PROD"* | grep '"file_path"' | grep -E '\.org"'Failed attempts can crash a Puma worker and leave a [BUG] report naming org-ruby or Onigmo functions. Many log pipelines do not ship puma_stderr.log by default, so check the file on disk.
# Native Ruby crashes whose backtrace runs through org-ruby or Onigmo
PUMA=/var/log/gitlab/puma/puma_stderr.log
zgrep -B1 -A20 '\[BUG\]' "$PUMA"* \
| grep -E 'org-ruby|headline\.rb|regexp_helper\.rb|regexp_matcher\.rb|match_at|onig_search_gpos|onig_compile|compile_tree|compile_length_tree|rb_str_sub_bang'For any project named in the checks above, look for an abnormally long #+TODO: line, and note who committed it.
# In a checkout of a suspect repository: oversized TODO keyword lines
rg -l --glob '**/*.org' '^\#\+(TODO|SEQ_TODO|TYP_TODO):.{500,}'A clean result does not prove you are safe. GitLab warns that a successful exploit can be quiet. If you find hits, also hunt for new files owned by git in /tmp, unexpected child processes of Puma, and changed crontabs or SSH keys for the git user. Ready-made Sigma rules are in GitLab’s detection repository.
GitLab’s detection notes suggest reducing public visibility until you patch. These steps narrow the attack path. None of them fix the bug.
None of these allow code execution. Two are rated high and depend on specific configurations.
These are fixed only in 19.3.6, 19.4.3 and 19.5.1. The backport releases, 19.2.9 and older, carry the critical fix alone, so an instance on a backport line still has them until it moves to 19.3.6 or later. Exact affected ranges per CVE
Dates are UTC.
2026-10-12
GitLab releases 19.4.2, 19.3.5 and 19.2.8, fixing CVE-2026-97229, an earlier Onigmo overflow reached through CI/CD rules.
2026-10-13
Rapid7 reports it has reproduced code execution for CVE-2026-97229 on an unpatched GitLab CE image.
2026-10-20
GitLab's security team publishes detection rules for the Org-mode render path and Onigmo worker crashes.
2026-10-21
GitLab releases 19.5.1, 19.4.3, 19.3.6 and backports to 19.2.9, 19.1.9, 19.0.10 and 18.11.13, fixing CVE-2026-110264 and 11 other issues.
19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, or any later release in the same line. Anything older than 18.11 must upgrade to at least 18.11.13, following GitLab's required upgrade stops.
Yes. The 12 October releases (19.4.2, 19.3.5 and 19.2.8) fixed a different regular expression bug, CVE-2026-97229. CVE-2026-110264 is fixed one patch later, in 19.4.3, 19.3.6 and 19.2.9.
No. GitLab.com already runs the fix. Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later already include it.
According to GitLab's detection notes, GitLab renders .org files with the org-ruby gem, which escapes the keywords on a file's #+TODO: line once, then passes the raw keyword into a second regular expression. A keyword with more than 32,767 repeats overflows a counter in Ruby's Onigmo regex engine and causes an out-of-bounds write, which can be turned into a command run as the git user. The notes say the attacker needs no login, only a public project that holds the crafted .org file.
No exploitation had been reported, and the CVE was not in CISA's Known Exploited Vulnerabilities catalog, as of 21 October 2026. The bug class is well understood, though: Rapid7 reproduced code execution for the closely related CVE-2026-97229 within a day of its fix.
GitLab's advisory lists none. Its detection notes suggest reducing public visibility until you patch: make existing public projects private or internal, restrict the Public level so non-admins cannot create new ones, and turn off open sign-up. None of this fixes the bug, and signed-in users can still reach the renderer. Upgrade as soon as you can.
On a single-node instance, yes, for 19.4.3 and 19.3.6, which run database migrations before GitLab starts. Multi-node instances can apply them without downtime using GitLab's zero-downtime upgrade procedure.