Direct answer: If you run a self-managed GitLab server, upgrade now to the fixed release for your branch: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, or 18.11.13. GitLab patched CVE-2026-110264 on October 21, 2026, a maximum-severity CVSS 10.0 flaw that, under certain conditions, could let an unauthenticated attacker run arbitrary code on the server. Crucially, servers patched in GitLab’s October 12 release are still in scope, because those fixed versions sit one patch below the new ones.
What CVE-2026-110264 is
CVE-2026-110264 is an integer overflow in the regular expression compiler used by GitLab, in the Onigmo engine bundled with Ruby. In GitLab’s own wording, the flaw could, under certain conditions, allow an unauthenticated user to execute arbitrary code on a GitLab server when a specially crafted regular expression is compiled. GitLab has not publicly spelled out those exact conditions in its release notes, which is itself a reason to patch rather than try to judge whether a particular setup is safe.
The CVSS 3.1 vector published for the flaw is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. In plain terms: the attack is network-based, low in complexity, needs no privileges and no user interaction, and can change scope with high impact on confidentiality, integrity and availability. That combination is why it scores the maximum 10.0.
A compromised GitLab server is a serious incident, not just a single-host problem. Self-managed instances typically hold source code, CI/CD pipelines, build secrets, deployment credentials and access tokens. An attacker who gains code execution on the server could plausibly reach much further into an organisation’s development and deployment workflow, so this patch should be treated as urgent for any internet-facing instance.
Which GitLab versions are affected
Every self-managed GitLab Community Edition and Enterprise Edition release from version 7.0 onward is affected, up to the fixed releases below. Version 7.0 dates back to 2014, so the flaw reaches across roughly 12 years of releases. It also covers the backported branches outside GitLab’s normal maintenance window, which is why the fix list is unusually long.
Only self-managed installations need to act. GitLab has confirmed that GitLab.com is already running the patched version, and GitLab Dedicated tenants on the internal releases 19.3.5-internal0 and 19.4.2-internal0 or later already include the fix.
| If you run | Upgrade to |
|---|---|
| 19.5 before 19.5.1 | 19.5.1 |
| 19.4 before 19.4.3 | 19.4.3 |
| 19.3 before 19.3.6 | 19.3.6 |
| 19.2 before 19.2.9 | 19.2.9 |
| 19.1 before 19.1.9 | 19.1.9 |
| 19.0 before 19.0.10 | 19.0.10 |
| 7.0 through 18.11, before 18.11.13 | 18.11.13 |
There is no workaround listed for this flaw. If you cannot upgrade immediately, reducing exposure is the sensible interim step: put the web interface behind a VPN or IP allowlist and prioritise internet-facing instances first, but treat that as a delay tactic, not a fix.
Why the October 12 patch does not cover you
This is the trap that makes CVE-2026-110264 easy to miss. On October 12, 2026, GitLab patched a separate maximum-severity regular expression flaw, CVE-2026-97229, in versions 19.4.2, 19.3.5 and 19.2.8. Many administrators quite reasonably patched then and moved on.
The October 21 fixed versions sit one patch above those October 12 builds on each branch. So a server running 19.4.2, 19.3.5 or 19.2.8 is still vulnerable to CVE-2026-110264 and needs to be upgraded again. Do not rely on a recent patch date alone: check the exact version number against the table above.
The two flaws are related in theme but distinct. Both involve the regular expression engine, and both were reported through GitLab’s HackerOne programme by the researcher known as joaxcar. The October 12 flaw was reached through CI/CD configuration, while analyses of GitLab’s detection material for CVE-2026-110264 point to a different route: rendering of Org-mode (.org) files, where a crafted file in a public project could trigger the overflow when GitLab renders it. That reported route matters because it does not require the attacker to have an account or submit a pipeline.
Is CVE-2026-110264 being exploited in the wild?
As of the reporting on October 22, 2026, GitLab had reported no sign that the flaw had been used in attacks, and it was not listed in the US CISA Known Exploited Vulnerabilities catalogue. That is reassuring, but it is not a reason to wait. Maximum-severity, unauthenticated flaws in widely deployed software tend to attract attention quickly once patches and detection rules are public, and the absence of a KEV listing on one date does not guarantee the same position later.
GitLab published two detection rules to help administrators look for exploitation attempts: one named Onigmo native worker crash and one named Org mode render error burst. A burst of render errors or native worker crashes in application logs is worth investigating, but GitLab’s own detection guidance cautions that a successful exploit does not reliably crash the server. In other words, clean logs do not prove an instance was never targeted.
If you find signs of compromise, preserve logs before rebuilding or restoring, rotate secrets and tokens that lived on or passed through the instance, and review repositories and pipelines for unexpected changes. A patch closes the hole; it does not undo access an attacker may already have gained.
What else the October 21 release fixes
The October 21 release is a critical patch release, not a single-flaw update, so upgrading clears more than CVE-2026-110264. Coverage of the release also lists a high-severity account takeover path, CVE-2026-15723, that applies when both SAML and LDAP auto-linking are enabled, and an OAuth and OpenID Connect cache poisoning issue, CVE-2026-112212. If either of those configurations applies to you, that is a second reason not to postpone the same upgrade.
Plan the upgrade window carefully. Some coverage notes that the 19.4.3 and 19.3.6 releases include database migrations that can cause downtime on single-node servers, so schedule accordingly, take a backup first, and verify the reported version on every host after the upgrade. For background on how GitLab flaws have been handled before, see our earlier coverage of a GitLab AI Gateway vulnerability, and for the same patch-first discipline in other widely used platforms, our explainers on the Cisco SD-WAN zero-day and the Citrix NetScaler zero-day.
How to patch and verify, step by step
- Find your exact GitLab version on every self-managed host, including test and staging servers that are reachable from the internet.
- Match it to the fixed release for its branch in the table above.
- Back up the instance, then upgrade using GitLab’s official upgrade path for your installation method, whether that is the Linux package, Docker, Helm chart or source install.
- After the upgrade, confirm the new version is reported correctly, and check that services, runners and integrations are healthy before closing the maintenance window.
- Review application logs for the detection signals above, especially on instances that were internet-facing while unpatched.
- Rotate any credentials, tokens or secrets that could have been exposed if you find evidence of compromise, and review repository and pipeline changes.
Frequently asked questions
What is CVE-2026-110264?
It is a CVSS 10.0 integer overflow flaw in GitLab’s regular expression compiler that, under certain conditions, could let an unauthenticated user run arbitrary code on a self-managed GitLab server. GitLab patched it on October 21, 2026.
Which GitLab versions are affected by CVE-2026-110264?
All self-managed GitLab Community Edition and Enterprise Edition versions from 7.0 up to the fixed releases: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. GitLab.com and already-patched GitLab Dedicated tenants are not affected.
I patched GitLab on October 12. Am I safe?
No, not against this flaw. The October 12 fixes for CVE-2026-97229 were 19.4.2, 19.3.5 and 19.2.8, which are all below the new fixed versions. You need to upgrade again to 19.4.3, 19.3.6, 19.2.9 or the fixed release for your branch.
Is there a workaround for CVE-2026-110264?
GitLab lists no workaround. Upgrading to the fixed version for your branch is the fix. Restricting web access behind a VPN or IP allowlist can reduce exposure temporarily, but it does not replace the patch.
Has CVE-2026-110264 been exploited in the wild?
As of reporting on October 22, 2026, GitLab reported no signs of exploitation and the flaw was not in CISA’s Known Exploited Vulnerabilities catalogue. That status can change, so patching promptly is still the right move.