GitLab Patched a CVSS 10 Unauthenticated RCE (CVE-2026-110264) — and Patching on Oct 12 Was Not Enough
GitLab released a critical patch on 21 October 2026 for CVE-2026-110264: an integer overflow in the bundled Onigmo regular-expression compiler that can let an unauthenticated attacker run code on self-managed GitLab. It is rated CVSS 10.0 and every self-managed CE/EE version from 7.0 (2014) onward is in range. Fixed versions are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13; gitlab.com was already patched. The trap: a separate critical regex fix shipped on 12 October, and operators who stopped there are NOT protected against this one — you have to upgrade again. Check your version with "sudo gitlab-rake gitlab:env:info" and compare against the fixed list. As of 22 October 2026 GitLab reports no public proof-of-concept and no known in-the-wild exploitation, but with a CVSS 10, roughly 2,700+ internet-exposed GitLab CE instances tracked by Shadowserver, and the "patch again" confusion, this is a patch-now item. The bug was reported by the researcher joaxcar through HackerOne. PlayCISO is relaying GitLab’s own advisory and independent reporting; verify against the vendor advisory before changing production systems.
GitLab shipped a critical security patch on 21 October 2026 for CVE-2026-110264, an unauthenticated remote code execution bug rated CVSS 10.0. It affects self-managed GitLab Community and Enterprise Edition all the way back to version 7.0 (2014). GitLab.com was already patched. If you run your own GitLab, this is a patch-now item — and if you only applied the earlier 12 October regex fix, you are not covered.
What it is
The flaw is an integer overflow in the bundled Onigmo regular-expression compiler. Processed through the wrong path, it can let an attacker who has not authenticated execute code on the server — which, for a system that holds your source code, CI/CD pipelines, deploy keys and registry credentials, is about as bad as it gets. That is why GitLab assigned it the maximum CVSS score of 10.0. The vulnerability was reported responsibly by the researcher joaxcar through HackerOne.
Who is affected
Every self-managed CE/EE version from 7.0 (2014) onward is in range, specifically anything before these fixed releases:
- All versions 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
- 19.5 before 19.5.1
Only currently supported branches (18.11 and later) receive a patch. If you are on an end-of-life version (18.10 or earlier — the advisory frames support around the 18.x line), there is no backport for you and the fix is an upgrade to a supported release.
Check your version
On the host where GitLab is installed, run:
sudo gitlab-rake gitlab:env:infoCompare the reported version against the fixed list above.
The "I patched on the 12th" trap
This is the part catching people out. A separate critical regex fix shipped on 12 October 2026. Plenty of operators patched then, saw "regex fix, done," and moved on. CVE-2026-110264 is a different bug, patched on 21 October. Applying the 12 October release does not protect you against it. The only safe state is being on one of the 21-October fixed versions (or later on the same branch).
What to do now
- Upgrade to a fixed version: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13, or later on the same branch.
- Confirm with
sudo gitlab-rake gitlab:env:infoand restart/redeploy the affected services. - Reduce exposure in the interim if you cannot patch immediately: restrict public access to the instance, put it behind SSO or a VPN, and make sure your WAF and monitoring are watching it. These reduce attack paths — they are not a substitute for the patch.
- If it was internet-facing and unpatched, treat it as potentially at risk, review access logs, and run your incident-response process. GitLab reports no known exploitation yet, but a CVSS 10 unauthenticated RCE on an exposed instance warrants a look.
Why this matters beyond GitLab
A source-control and CI/CD server is a high-value target precisely because it reaches everything else — code, secrets, pipelines, production. The lesson that keeps repeating in 2026 is unglamorous: know which internet-facing services you run, track their versions, and have a path to patch a CVSS 10 the day it drops. Shadowserver tracks several thousand internet-exposed GitLab CE instances; the ones that get hurt are rarely the ones that patched on day one. If you are putting an incident-response path in writing, our free Incident Response Plan Builder and the rest of the PlayCISO security tools are a starting point.
Sources
This write-up relays GitLab’s own advisory and independent reporting. Verify against the vendor advisory before changing production systems:
- GitLab Critical Patch Release 19.5.1 (GitLab)
- CVE-2026-110264 (Tenable / NVD)
- GitLab warns of new max severity code execution vulnerability (BleepingComputer)
PlayCISO is not affiliated with GitLab. No confirmed in-the-wild exploitation was reported by GitLab as of 22 October 2026.
Ready to practise the decisions these articles describe?
Run a free War Room →