GitLab on 21 October shipped fixes for GitLab CVE-2026-110264, a CVSS 10.0 flaw that could let an unauthenticated attacker run code on a self-managed GitLab server. The awkward part is timing. Administrators who rushed out the 12 October critical patch are running versions that are vulnerable again, because the new fixed releases sit one patch level above that update.
Every self-managed GitLab instance from version 7.0 onward is affected, and the fix is to 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 is already patched, and Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 or later need no action. If you upgraded on 12 October, you are not done.
What is CVE-2026-110264?
According to the GitLab patch release notes, the bug is an integer overflow in the regular expression compiler that, under certain conditions, allows code execution without logging in. The Hacker News reported that the affected code is Onigmo, the regex engine built into Ruby, which GitLab ships and patches in its own packages. A specially crafted regular expression triggers the overflow.
GitLab has not said what preconditions an attacker needs. The report came in through its HackerOne program from a researcher who goes by joaxcar. According to The Hacker News, it is the fourth code execution flaw that researcher has found in the regex engine within a month.
Why are servers patched on 12 October exposed again?
On 12 October GitLab fixed CVE-2026-97229, another unauthenticated CVSS 10.0 overflow in the same regex compiler. Those releases were 19.4.2, 19.3.5 and 19.2.8, and they covered only the 19.2 branch and later.
The new bug reaches much further back. GitLab says every version since 7.0, which shipped in 2014, is affected. The 12 October builds sit below the new fixed versions, so a server that took that update is still exposed to CVE-2026-110264.
GitLab also backported the fix to 18.11.13, 19.0.10, 19.1.9 and 19.2.9 outside its normal schedule. Four of those branches fall outside its usual support window, which covers only the current and previous two monthly releases. Vendors do not do that for medium bugs.
Which versions fix it?
19.5 before 19.5.1: upgrade to 19.5.1
19.4 before 19.4.3: upgrade to 19.4.3
19.3 before 19.3.6: upgrade to 19.3.6
19.2 before 19.2.9, 19.1 before 19.1.9, 19.0 before 19.0.10: upgrade to the matching patch
Anything from 7.0 through 18.11 before 18.11.13: upgrade to 18.11.13 or later
The 19.4.3 and 19.3.6 releases include database migrations. Single-node servers will have downtime while those run. Multi-node installations can follow GitLab's zero-downtime upgrade process.
The same release fixes 11 other issues. Two are rated high: CVE-2026-15723, an account takeover that applies only when both SAML and LDAP auto-linking are switched on, and CVE-2026-112212, cache poisoning in the OAuth and OpenID Connect discovery endpoints that could redirect sign-in flows.
GitLab says it has seen no sign of exploitation, and no public proof of concept exists for the new bug. That was also true of the earlier one until Rapid7 reproduced code execution for CVE-2026-97229 and published a proof of concept.
What should you check after upgrading?
Upgrading closes the hole. It does not tell you whether someone used it first.
GitLab released two detection rules that run against its application logs, called Onigmo native worker crash and Org mode render error burst. Run them over as much log history as you keep, not only the last few days.
For the 12 October bug, Rapid7 showed commands running as the git user inside a GitLab application worker. That process holds everything GitLab itself needs to work, which on a typical self-managed server includes:
The Rails secrets, including the key that decrypts CI/CD variables stored in the database.
Database access, and with it every project and group CI/CD variable, many of which are cloud and deploy credentials.
Runner authentication tokens. With one of those, someone can register a fake runner, pick up jobs and receive the secrets those jobs are given.
Personal, project and group access tokens, deploy tokens and deploy keys.
GitLab's advisory gives no rotation guidance, so this is your call. If your instance faces the internet, allows open sign-up, or lets ordinary users create public projects, which was the delivery path Rapid7 used for the earlier bug, let the logs decide. If you find the crash patterns, or you cannot tell either way, rotate.
A sensible order is runner tokens first, then CI/CD variables that carry cloud, registry and deploy credentials, then high-privilege access tokens. While you are there, look at the runner list for entries nobody recognises and check the audit log for new tokens, admins or SSH keys created since early October.
Four regex bugs in a month suggests nobody is finished with Onigmo yet, so book the next maintenance window now rather than waiting for the fifth.
Quick answers
Is GitLab CVE-2026-110264 fixed by the 12 October patch?
No. The 12 October releases (19.4.2, 19.3.5 and 19.2.8) fixed a different bug, CVE-2026-97229. Servers on those versions are still exposed to CVE-2026-110264 and need the 21 October releases.
Which GitLab versions fix CVE-2026-110264?
GitLab 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, released on 21 October 2026. Every self-managed version from 7.0 up to those releases is affected.
Do GitLab.com or GitLab Dedicated users need to do anything?
No. GitLab.com already runs the fixed code, and Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 or later already have the fix.
