GitLab CVE-2026-110264. Patch Now. Hunt for Compromise.
An unauthenticated remote code execution flaw in self-managed GitLab, back to version 7.0. Clear steps to find and patch every instance, and a reactive hunt to check whether yours or your clients' were hit.
At a Glance
Facts from GitLab's critical patch release of 21 October 2026. Last updated 22 October 2026, 00:00 BST.
10.0
CVSS v3.1, rated Critical by GitLab. Unauthenticated remote code execution on the GitLab server.
CE/EE from 7.0
All self-managed GitLab Community and Enterprise Edition versions from 7.0 before the fixed releases. GitLab.com is already patched.
Patch released
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 lists no workaround.
None reported
No public reports of exploitation at the time of writing, and not in CISA's Known Exploited Vulnerabilities catalogue. GitLab has published threat detections for exploitation attempts.
GitLab patches CVE-2026-97229, a separate critical regex flaw, in 19.4.2, 19.3.5 and 19.2.8.
GitLab releases 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13 for CVE-2026-110264. Instances on the 12 October releases are still affected.
Patch internet facing self-managed instances first. Restrict access to anything you cannot patch today, and hunt for signs of compromise.
What to Do in the Next 24 Hours
Proactive on the left. Reactive on the right. Tick both tracks.
Find and patch
- Inventory every self-managed GitLab instance, including test servers, Docker hosts and Helm deployments run by other teams or clients.
- Upgrade to the fixed release for your version line. Patched for CVE-2026-97229 on 12 October? You still need this update.
- Plan downtime for single-node instances on 19.4.3 or 19.3.6, which run database migrations before GitLab starts.
- Cannot patch today? Put internet facing instances behind a VPN or IP allow-list until you can.
Hunt and respond
- Use GitLab's two threat detections: 'Onigmo native worker crash' and 'Org mode render error burst'.
- Look for unexpected child processes of GitLab services, such as shells, interpreters or download tools run as the git user.
- Review recently created users and admins, new personal access tokens and new SSH keys.
- If you find something: isolate the server, preserve logs, then rotate runner tokens, deploy keys and CI/CD variables.
Proactive: Find and Patch GitLab
Work through these on every self-managed GitLab instance you or your clients run.
Find your GitLab instances
Check asset inventories, DNS and certificate records for GitLab hostnames, and look for servers and containers running GitLab packages. Don't forget instances stood up for one project or one client.
# Omnibus packages (Debian/Ubuntu, RHEL family)
dpkg -l | grep -E "gitlab-(ce|ee)"
rpm -qa | grep -E "gitlab-(ce|ee)"
# Containers
docker ps --format "{{.Image}} {{.Names}}" | grep -i gitlab
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep -i gitlabCheck the running version
Read the version on each server, or ask the API with a personal access token.
# On the server (Omnibus or Docker)
sudo cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
# Through the API
curl -s --header "PRIVATE-TOKEN: <your_token>" https://gitlab.example.com/api/v4/versionCompare it with the fixed release for its line: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. Anything lower in the same line is affected. Versions older than 18.11 have no direct patch and need to follow the GitLab upgrade path to a fixed release.
Upgrade to the fixed release
Pick the fixed release for the line you run. Use gitlab-ce for Community Edition.
# Debian / Ubuntu (example for the 19.4 line)
sudo apt-get update && sudo apt-get install gitlab-ee=19.4.3-ee.0
# RHEL family
sudo dnf install gitlab-ee-19.4.3-ee.0.el9
# Docker
docker pull gitlab/gitlab-ee:19.4.3-ee.019.4.3 and 19.3.6 include database migrations, so single-node instances will be down until they finish. Multi-node instances can use GitLab's zero-downtime upgrade process. Helm users need the chart release that ships a fixed version. If you build GitLab from source, make sure the Ruby runtime patch is applied as well as the Rails code.
Restrict access until patched
GitLab lists no workaround. If you can't patch straight away, take the instance off the open internet: put it behind a VPN, or allow only known IP ranges at the firewall or in GitLab's bundled NGINX.
# /etc/gitlab/gitlab.rb (adjust ranges), then: sudo gitlab-ctl reconfigure
nginx['custom_gitlab_server_config'] = "allow 10.0.0.0/8;\nallow 203.0.113.0/24;\ndeny all;\n"This reduces who can reach the server. It is not a fix, so patch as soon as you can.
Patch the other flaws in the same release
The same release fixes two high severity issues on the 19.3, 19.4 and 19.5 lines: CVE-2026-15723 (CVSS 8.2), account takeover when OmniAuth SAML and LDAP auto-linking are both enabled, and CVE-2026-112212 (CVSS 7.5), cache poisoning of OAuth/OIDC discovery documents. These two are fixed only in 19.5.1, 19.4.3 and 19.3.6. The 19.2.9, 19.1.9, 19.0.10 and 18.11.13 backports carry the CVE-2026-110264 fix only, so if you run 19.2 or older, plan a move to 19.3.6 or later.
Free Checker Scripts
Tested by the CybaVerse threat hunt team. Run it on any Linux host that runs GitLab, or point it at a mounted disk, to get a clear verdict per install. Built for businesses, internal IT teams and MSPs checking their own or their clients' estates.
check-gitlab-110264.sh
Finds Omnibus, source and Docker installs of GitLab, reads each version and maps it to the fixed release for its line. It also gives a verdict for CVE-2026-15723 and CVE-2026-112212, checks gitlab.rb for the SAML plus LDAP auto-link setup that CVE-2026-15723 needs, and hunts Puma, Sidekiq, Workhorse, Rails and kernel logs for Onigmo crashes and Org render timeouts.
sudo bash check-gitlab-110264.shRun as root so it can read gitlab.rb, the logs and Docker. Options: LOG_LINES=500000 to read more log lines, GITLAB_ROOT=/mnt/disk to check a mounted disk or snapshot offline.
Other platforms
GitLab self-managed runs on Linux only, so there is no Windows checker for this threat. For Helm or Kubernetes installs, check the image tag of the webservice and Sidekiq pods with the commands in Step 1 above and compare it with the fixed releases.
Read-only by design
The script reads files and runs only read commands: docker ps, docker images, docker exec to read the version manifest inside a GitLab container, and journalctl to read kernel messages. It does not change configuration, restart services or write files. The optional USE_RAKE=1 mode also runs gitlab-rake gitlab:env:info, which starts Rails and is slow. Review any script before you run it.
Verdicts
- PATCHEDThe version is at or above the fixed release for its line, or is 19.6 or later.
- LIKELY VULNERABLEThe version is below the fix for its line, or is on a 7.0 to 18.10 line with no direct fix.
- UNKNOWNThe version can't be read. Confirm it in Admin Area > Help.
Exit codes
| Code | Meaning |
|---|---|
| 0 | Every GitLab install found is PATCHED, or no GitLab was found |
| 1 | At least one LIKELY VULNERABLE |
| 2 | At least one UNKNOWN, none vulnerable |
| 3 | Patched, but the log hunt found entries to review |
MSPs and internal IT teams can use the exit code in RMM or deployment tooling to flag hosts at scale.
Know the limits
- The verdict comes from the version only. The script cannot detect a hotpatched Onigmo or a custom build.
- Helm and Kubernetes installs aren't inspected, and the
gitlab.rbcheck doesn't see Helm values,GITLAB_OMNIBUS_CONFIGor environment overrides. - Only standard Omnibus and source log paths are read, and only the last 200,000 lines of each log by default. Native crash reports often are not shipped to a SIEM.
- A clean result is not proof of safety. GitLab says a successful exploit is quiet and does not reliably crash, and it hasn't disclosed the exact preconditions.
Reactive: How to Hunt
Hunt on behaviour: look for crashes around the regex engine and for activity that follows code execution on a GitLab server. CybaOps can run these hunts across your estate or your clients'.
Onigmo worker crashes and Org render errors
GitLab's published detections look for native crashes in the bundled Onigmo regex engine and bursts of Org-mode render errors. Search Puma, Sidekiq and Rails logs for both. A quiet log is not proof of safety, because a successful attack may not crash anything.
# Native crashes in Puma or Sidekiq workers
sudo grep -iE "onigmo|segmentation fault|SIGSEGV|SIGABRT" /var/log/gitlab/puma/*.log /var/log/gitlab/sidekiq/current 2>/dev/null | tail -50
# Render and regex errors in Rails exceptions
sudo grep -iE "org|RegexpError|too many range repeat" /var/log/gitlab/gitlab-rails/exceptions_json.log 2>/dev/null | tail -100Odd child processes of GitLab services
Code execution through this flaw runs as the GitLab service account. Alert when Puma, Sidekiq or other GitLab processes start a shell, interpreter or download tool.
# Process tree for the git user
ps -u git -o pid,ppid,etime,cmd --forest | grep -vE "puma|sidekiq|gitaly|workhorse|postgres|redis|nginx" | head -60
# Outbound connections from GitLab processes
sudo ss -tpn | grep -E "puma|sidekiq|ruby" | head -50New users, admins and tokens
Review accounts and credentials created recently, especially admins and tokens you do not recognise.
sudo gitlab-rails runner 'User.where("created_at > ?", 14.days.ago).find_each { |u| puts [u.username, u.admin?, u.created_at].join(",") }'
sudo gitlab-rails runner 'PersonalAccessToken.where("created_at > ?", 14.days.ago).find_each { |t| puts [t.user&.username, t.name, t.scopes.join(" "), t.created_at].join(",") }' If you find signs of compromise
Isolate the server and preserve /var/log/gitlab before you change anything. Then rotate everything the GitLab server held: runner registration and authentication tokens, deploy keys and deploy tokens, CI/CD variables, personal and project access tokens, and integration secrets. Review recent admin and user creation, and rebuild from a known good backup if you cannot rule out persistence.
Tested detection pack: KQL and Sigma
Behavioural hunts from the CybaVerse threat hunt team. GitLab has published no IOCs, so these look for native worker crashes with Onigmo or org-ruby frames, bursts of Org-mode render timeouts, shells or network tools started by Puma, Sidekiq or Workhorse, and new or elevated admins. Treat hits as leads, and baseline your environment before you alert. Run them in CybaOps or any SIEM that supports KQL or Sigma.
The KQL queries are built for Microsoft Sentinel and Defender XDR. Replace the custom table names with your own, test them in your environment first and tune the thresholds to your baseline.
KQL hunting queries (Sentinel and Defender XDR)
Loading queries. If they don't appear, use the download link below.Sigma: Linux syslog: GitLab worker crash with Onigmo or org-ruby frames
title: GitLab Worker Native Crash With Onigmo or org-ruby Frames (CVE-2026-110264)
id: 3f6a0d2e-9b7c-4c1e-8a51-7d2e4b0c9a11
status: experimental
description: |
Native Ruby [BUG] crash or segfault in GitLab Puma/Sidekiq logs whose text references the Onigmo regex engine
or the org-ruby gem. Based on the logic of GitLab's TLDR rule "Onigmo native worker crash"
(id 58461d1f-2ad8-41a8-861e-57c8b697657f). Corroborating only: a successful exploit may not crash.
Requires the whole [BUG] report to be ingested as one event (multiline); otherwise correlate per host.
references:
- https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
- https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/onigmo_native_worker_crash.md
author: Cybaverse
date: 2026-10-21
tags:
- attack.initial-access
- attack.t1190
- cve.2026-110264
logsource:
product: gitlab
service: puma_stderr
detection:
selection_crash:
message|contains:
- '[BUG]'
- 'Segmentation fault'
- 'Bus Error'
selection_frames:
message|contains:
- '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'
condition: selection_crash and selection_frames
falsepositives:
- Benign org-ruby/Onigmo bugs on malformed but harmless .org files
- Crash reports replayed from backups or test logs
level: criticalSigma: GitLab exceptions log: Org-mode render timeout
title: GitLab Org-mode Render Timeout (CVE-2026-110264 attempt indicator)
id: 5a7e2c19-6d40-4f8b-b3e2-9c0d1f6a8e27
status: experimental
description: |
Timeout::Error from GitLab's OtherMarkup renderer on an .org file in exceptions_json.log. GitLab's TLDR
"Org mode render error burst" rule uses this as the base event and alerts at 5+ per client in 30 minutes;
implement that threshold as a correlation in your SIEM.
references:
- https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/org_mode_render_error_burst.md
author: Cybaverse
date: 2026-10-21
tags:
- attack.initial-access
- attack.t1190
- cve.2026-110264
logsource:
product: gitlab
service: exceptions_json
detection:
selection:
exception.class: 'Timeout::Error'
extra.class_name: 'OtherMarkup'
extra.file_name|endswith: '.org'
condition: selection
falsepositives:
- Large legitimate .org documents
level: mediumSigma: Linux process creation: shell or network tool started by Puma, Sidekiq or Workhorse
title: Shell or Network Tool Spawned by GitLab Puma, Sidekiq or Workhorse
id: 8c1d4e7a-2f35-4b6e-9d08-5a9e1c3b7f42
status: experimental
description: |
A GitLab application process (Puma, Sidekiq, gitlab-workhorse) starts a shell, scripting interpreter or network
tool. GitLab's TLDR response guidance for CVE-2026-110264 says to hunt for unexpected child processes of Puma;
the RCE runs as the git user. Baseline first: hooks and some features legitimately use sh.
references:
- https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
- https://gitlab.com/gitlab-security-oss/tldr/-/blob/main/Detections/platforms/GitLab/Vulnerability%20Detections/org_mode_render_error_burst.md
author: Cybaverse
date: 2026-10-21
tags:
- attack.execution
- attack.t1059.004
- attack.t1190
- cve.2026-110264
logsource:
product: linux
category: process_creation
detection:
selection_parent:
- ParentCommandLine|contains:
- 'puma: cluster worker'
- 'puma '
- 'sidekiq '
- ParentImage|endswith:
- '/gitlab-workhorse'
- '/puma'
- '/sidekiq'
selection_child:
Image|endswith:
- '/sh'
- '/bash'
- '/dash'
- '/python'
- '/python3'
- '/perl'
- '/nc'
- '/ncat'
- '/socat'
- '/curl'
- '/wget'
- '/busybox'
- '/base64'
- '/crontab'
- '/whoami'
- '/id'
condition: selection_parent and selection_child
falsepositives:
- Custom server hooks, import/export and backup jobs, admin rake tasks
level: highGitLab's own threat detections
GitLab published two threat detections for this CVE in its open-source TLDR project, each with a Sigma rule and a raw log query. Treat them as the authoritative version and use them alongside ours. Our rules follow the same logic and add a process-creation rule.
GitLab CVE-2026-110264 FAQ
Short answers based on GitLab's critical patch release as of 21 October 2026.
What is CVE-2026-110264?
A critical flaw in self-managed GitLab Community and Enterprise Edition. GitLab says an unauthenticated user could run arbitrary code on the GitLab server because of an integer overflow when a specially crafted regular expression is compiled. GitLab rates it CVSS 10.0. The fix patches the Onigmo regex engine in the Ruby runtime that GitLab bundles.
Which versions are affected?
All GitLab CE/EE 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 and 19.5 before 19.5.1. GitLab.com is already patched, and GitLab Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later need no action.
I patched for CVE-2026-97229 on 12 October. Am I safe?
No. The 12 October releases (19.4.2, 19.3.5 and 19.2.8) are below the fixed versions for CVE-2026-110264, so you need to upgrade again.
Is there a workaround?
GitLab lists no workaround. Upgrading is the fix. If you cannot upgrade straight away, reduce exposure by putting the instance behind a VPN or an IP allow-list until you can.
Will the upgrade cause downtime?
On single-node instances, yes for 19.4.3 and 19.3.6, because their database migrations must finish before GitLab starts. Multi-node instances can follow GitLab's zero-downtime upgrade process.
Is it being exploited?
There were no public reports of exploitation at the time of writing, and it was not in CISA's Known Exploited Vulnerabilities catalogue. GitLab has published threat detections for exploitation attempts. Treat internet facing instances as a target and patch now.
What else does this release fix?
Eleven more issues, including CVE-2026-15723 (CVSS 8.2), an account takeover when OmniAuth SAML and LDAP auto-linking are both enabled, and CVE-2026-112212 (CVSS 7.5), cache poisoning of OAuth/OIDC discovery documents. These are fixed in 19.5.1, 19.4.3 and 19.3.6 only.
Detect and Remediate GitLab CVE-2026-110264 Across Your Estate
CybaOps finds vulnerable GitLab and other exposed services across every system you look after, whether that's your own business or your clients'. It runs threat hunts through our SOC and drives remediation through to a verified fix, so proactive remediation and reactive hunting happen in one place.
Sources
- 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 (21 October 2026)
- GitLab: Critical Patch Release 19.4.2, 19.3.5, 19.2.8 (CVE-2026-97229, 12 October 2026)
- GitLab omnibus-gitlab: Ruby regexp repeat ID overflow patch (Onigmo)
- CISA: Known Exploited Vulnerabilities catalogue
- GitLab TLDR: open-source threat detections