Your self-managed GitLab server might be accepting remote code execution from anyone who sends the right request, because GitLab just released emergency fixes for a maximum-severity flaw that affects every version going back to 7.0, which shipped in 2014, and if you patched nine days ago during the last security release, you are still in the blast radius.
The flaw is tracked as CVE-2026-110264, and it scores a perfect 10.0 on the CVSS scale.
GitLab says it allows an unauthenticated user to run arbitrary code on the server due to an integer overflow during the compilation of a specially crafted regular expression. They haven't said what the exact preconditions are.
What Makes CVE-2026-110264 a Maximum-Severity Threat
Quick Security Checklist
- Scan your system or website
- Update all dependencies
- Change passwords
- Enable 2FA
A 10.0 score means no privileges required, no user interaction, and total system compromise.
The vulnerability lives in Onigmo, Ruby's built-in regular-expression compiler, which GitLab ships inside its own packages. Because GitLab has shipped this engine in every release since 7.0, the weakness travels with it.
An attacker doesn't need an account. They don't need to trick an administrator into clicking a link. They just need to trigger the compiler with a malicious regex.
GitLab reports no sign the flaw has been used in attacks yet, and it is not in CISA's known exploited vulnerabilities catalog as of October 22. That window is your opportunity to patch before someone weaponizes it.
The October 12 Patch Trap
If you updated your server on October 12, you are not safe.
That release fixed CVE-2026-97229, another 10.0 overflow in the same regex compiler, but it only covered versions 19.2 and later. The new fixed versions sit exactly one patch above what you installed nine days ago.
If you run GitLab 19.2.8, you are vulnerable again. You need 19.2.9.
Who Needs to Patch Right Now
Only self-managed installations need to act.
GitLab.com already runs the fixed version. GitLab Dedicated tenants on internal releases 19.3.5-internal0 and 19.4.2-internal0 or later also have the fix.
GitLab fixed the flaw across seven versions at once, including four branches older than its standard patching policy:
|
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 |
GitLab normally patches the current release and the previous two monthly releases. Backporting a fix to 18.11.13, 19.0.10, 19.1.9, and 19.2.9 is a step the company reserves for severe issues.
How to Hunt for Exploitation Attempts
Because GitLab hasn't published the preconditions to reach the compiler, you can't rule yourself out by configuration. Patching is the only certain protection, and the advisory lists no interim workaround.
If you suspect someone tried, GitLab published two detection rules. They are part of the company's open-source TLDR framework, written in Sigma format against GitLab's own application logs:
- "Onigmo native worker crash"
- "Org mode render error burst"
An integer overflow in a compiler often ends in a crash before it ends in code execution. If your logs show a burst of these errors, treat it as a live attack.
The Other High-Severity Fixes You Shouldn't Ignore
The October 21 release fixes 11 security issues in total. Two of the others concern authentication.
- CVE-2026-15723 (CVSS 8.2) could allow a logged-in user to take over another account, but only when an administrator has enabled both SAML and LDAP auto-linking.
- CVE-2026-112212 (CVSS 7.5) is a cache-poisoning flaw in GitLab's OAuth and OpenID Connect endpoints. In setups using a shared cache, an attacker could redirect certain sign-in flows to a server they control.
What the Upgrade Will Cost You
Planning matters here, because the fix isn't just a file swap.
The 19.4.3 and 19.3.6 releases include database changes that run during the upgrade. On a single-node server, that means downtime while they finish.
GitLab says multi-node setups can apply the patch without downtime using its zero-downtime procedure. If you're running a single node, schedule a maintenance window.
Why This Researcher Keeps Finding These Bugs
This is the fourth code-execution flaw in GitLab's regex engine reported in a month by the same researcher, who uses the handle joaxcar.
The first three stopped at version 19.2. This one reaches back to 7.0.
The pattern is clear. The regex compiler is a complex, native-code component shipped inside a massive Ruby application. Every time a researcher looks closely at it, something breaks.
FAQ
What is CVE-2026-110264?
It is an unauthenticated remote code execution flaw in GitLab, rated 10.0 on the CVSS scale. It stems from an integer overflow in Ruby's Onigmo regular-expression compiler when compiling a specially crafted regex.
Does this affect GitLab.com or GitLab Dedicated?
No. GitLab.com already runs the patched version. GitLab Dedicated tenants running 19.3.5-internal0 or 19.4.2-internal0 and later are also fixed. Only self-managed installations need to act.
I patched on October 12. Am I safe?
No. The October 12 patch covered versions 19.2 and later, fixing a different regex flaw. The new fix is one patch above it, so you need to upgrade again to the versions listed in the table.
Which versions of GitLab are affected?
Every version from 7.0 through 19.5.0, depending on the branch. GitLab released fixes for seven branches, including backports to 18.11.13, 19.0.10, 19.1.9, and 19.2.9.
Is there a workaround if I can't patch immediately?
No. GitLab's advisory offers no interim workaround, and the company hasn't disclosed the preconditions required to reach the compiler. Updating is the only certain protection.
