Last updated: 24 October 2026. Sources are listed at the end.
On 21 October 2026, GitLab released patch versions for a CVSS 10.0 flaw, CVE-2026-110264. GitLab says it lets an attacker who isn’t logged in run code on the server “under certain conditions”. Every self-managed version back to GitLab 7.0 is affected. If you run your own GitLab, this CVE-2026-110264 guide tells you what to check and how to upgrade today.
The short answer
- GitLab.com is already patched. GitLab Dedicated customers don’t need to do anything.
- Self-managed CE and EE: upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13.
- Updated on 12 October? That isn’t enough. The 12 October release fixed a different CVSS 10 bug.
What is CVE-2026-110264?
GitLab describes it as an “integer overflow in the regular expression compiler” (CWE-190). The same release fixes 11 other CVEs, including two High ones: an OmniAuth-to-LDAP account takeover (CVE-2026-15723) and OAuth/OIDC cache poisoning (CVE-2026-112212).
GitLab hasn’t published the technical details. However, independent researchers point to how GitLab renders Org mode (.org) files. According to their analysis, the org-ruby gem passes #+TODO: keywords into Ruby’s regex engine without escaping them. A crafted file then overflows a counter in Onigmo, the regex engine, and writes outside its memory. The result is code running as the git user. Treat this explanation as likely, not confirmed.
Who is most exposed?
The malicious file has to sit in a project that someone can view. Therefore, the highest-risk instances are those with public projects or open sign-up, where anyone can create a project. A private instance behind a VPN is much harder to reach, but it still needs the patch.
Is CVE-2026-110264 being exploited?
Not yet, as far as we know. On 24 October, there was no confirmed exploitation, and the bug was not in CISA’s Known Exploited Vulnerabilities catalog. Some GitHub repositories claim to exploit it. At least one of them actually targets the older CVE-2026-97229, so treat them as unverified. Nevertheless, CISA rates the bug as automatable with “total” technical impact, so exploitation could start quickly.
Affected and fixed versions
| Your version | Fixed in |
|---|---|
| 19.5.0 | 19.5.1 |
| 19.4.0 – 19.4.2 | 19.4.3 |
| 19.3.0 – 19.3.5 | 19.3.6 |
| 19.2.0 – 19.2.8 | 19.2.9 |
| 19.1.0 – 19.1.8 | 19.1.9 |
| 19.0.0 – 19.0.9 | 19.0.10 |
| 7.0 – 18.11.12 | 18.11.13 (or upgrade further) |
Step 1: Check your version
# Omnibus install
sudo gitlab-rake gitlab:env:info | grep -i 'gitlab information' -A2
cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
# From anywhere, with a personal access token
curl -s --header "PRIVATE-TOKEN: <token>" https://gitlab.example.com/api/v4/versionStep 2: Back up and upgrade
First, take a backup and save your secrets:
sudo gitlab-backup create
sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /root/Then install the fixed package for your line. For example, on 19.5:
# Debian/Ubuntu
sudo apt-get update && sudo apt-get install gitlab-ee=19.5.1-ee.0
# RHEL family
sudo dnf install gitlab-ee-19.5.1-ee.0.el9Use gitlab-ce instead of gitlab-ee for the Community Edition. For Docker, switch the image to gitlab/gitlab-ee:19.5.1-ee.0 (or the -ce image) and recreate the container. Helm users should move to the chart release that ships GitLab 19.5.1.
Upgrade caveats
- The patch includes database migrations. Single-node instances will have a short downtime, so plan a window.
- If you are below 18.11, there is no patch for your line. You must follow the required upgrade stops (19.2, 19.5 and so on). GitLab’s upgrade path tool lists them.
- A background migration must finish before you upgrade past 19.5. Check Admin → Monitoring → Background migrations before each step.
If you can’t patch today
GitLab offers no official workaround. Still, you can reduce exposure while you schedule the upgrade:
- Put the instance behind a VPN or an IP allowlist.
- Turn off public sign-up (Admin → Settings → General → Sign-up restrictions).
- Restrict Public project visibility.
How to spot an attack attempt
GitLab has published two detections: an “Onigmo native worker crash” and an “Org mode render error burst”. In practice, look for:
[BUG]crash lines in/var/log/gitlab/puma/puma_stderr.log- Bursts of 502 errors when someone opens
.orgfiles - Repository files with very long
#+TODO:lines
sudo grep -n '\[BUG\]' /var/log/gitlab/puma/puma_stderr.log | tailIf you find signs of compromise, isolate the server, keep the logs and rotate runner tokens, deploy keys and CI/CD variables.
Quick checklist
- ☐ Version checked against the table above
- ☐ Backup taken, including
gitlab-secrets.json - ☐ Upgraded and background migrations finished
- ☐ Sign-up and public visibility reviewed
- ☐ Puma logs checked for crashes
Want an outside check of your DevOps tooling? Our VAPT services cover self-hosted Git, CI/CD and their secrets. This patch came in a very busy week; see our Black October fact-check for the rest.
Sources
- GitLab: patch release 19.5.1
- OpenCVE: CVE-2026-110264
- Zero Hunt: Org mode regex analysis
- eSecurity Planet: GitLab critical RCE patch
- GitLab 19 upgrade notes
- GitLab upgrade path tool
Want a second pair of eyes on your DevOps security? Our VAPT services cover CI/CD pipelines, self-hosted tools and how secrets are stored. For servers, see our Linux server hardening & security audit, or contact us.
