On October 21, 2026, GitLab shipped an emergency patch for CVE-2026-110264, a flaw rated the maximum CVSS 10.0. It lets an unauthenticated attacker run code on a self-managed GitLab server, and it reaches back to version 7.0, roughly twelve years of releases. If you run your own GitLab, you were on a vulnerable version until you upgraded. There's no workaround, so patching is the only fix.
What is CVE-2026-110264?
A critical, unauthenticated remote code execution flaw in self-managed GitLab, caused by an integer overflow in its regex compiler.
How severe is it?
CVSS 10.0, the maximum. No login is needed, and it affects every self-managed GitLab from version 7.0.
Is GitLab.com affected?
GitLab's own hosted service was already patched. The risk is to self-managed Community and Enterprise Edition installs.
Is it being exploited?
At the time of writing it wasn't in CISA's KEV catalog and there were no confirmed in-the-wild attacks, but a working exploit for a related flaw already existed.
What should I do?
Upgrade to the fixed release for your line immediately: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, or 18.11.13.
Key Takeaways
- CVE-2026-110264 is a CVSS 10.0, unauthenticated RCE in self-managed GitLab, patched on October 21, 2026.
- It affects every self-managed Community and Enterprise Edition install from version 7.0, about twelve years of releases.
- There's no workaround. Upgrading to the fixed release for your line is the only fix.
- GitLab backported the fix to seven version lines at once, so you don't have to jump to the newest major version.
- The root cause is in GitLab's bundled Ruby regex engine, so patching GitLab applies the fix.
- Your Git server sits inside your build pipeline, so a GitLab compromise can reach source code, secrets, and production.
What Happened
On October 21, 2026, GitLab published a critical patch release covering seven version lines at once: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13, for both Community and Enterprise Edition. The headline fix was CVE-2026-110264, which GitLab's advisory describes as an integer overflow while compiling a specially crafted regular expression that, under certain conditions, could let an unauthenticated user run arbitrary code on the server.
It was reported through HackerOne and rated CVSS 10.0, the maximum. The flaw sits in the regex engine GitLab bundles through Ruby, which is why the affected range stretches all the way back to version 7.0 (2014). It's also part of a run of regex-compiler flaws found in GitLab within the same month: an earlier critical bug, CVE-2026-97229, was patched on October 12, and the October 12 builds (19.2.8, 19.3.5, 19.4.2) are still inside the affected range of CVE-2026-110264. GitLab.com was already running a patched version.
Who Is Affected and Which Version to Install
Every self-managed GitLab from version 7.0 onward, Community and Enterprise Edition alike, is affected unless it's on a fixed build. GitLab normally patches only its three newest lines, but because this flaw is so severe, it backported the fix much further. Lines older than 18.11 get no fix and must move to a supported line.
Your line | Fixed version |
|---|---|
19.5.x | 19.5.1 |
19.4.x | 19.4.3 |
19.3.x | 19.3.6 |
19.2.x | 19.2.9 |
19.1.x | 19.1.9 |
19.0.x | 19.0.10 |
7.0 to 18.11 | 18.11.13 |
Anything below your line's fixed version, including builds from earlier in October, is still exposed. Because the root cause is in the bundled Ruby regex engine, installing a fixed GitLab release applies the fix; there's no separate component to patch.
What to Do Now
- Check your version. On a self-managed instance, confirm the running version against the fixed release for your line. If you upgraded on October 12 for CVE-2026-97229, you're still exposed to this one; the fixed versions sit one patch higher.
- Upgrade immediately. Follow GitLab's documented upgrade path for your line. There's no workaround, so this is the only real fix. Prioritize any instance reachable from the internet.
- Restart and verify. After upgrading, confirm the new version is actually running, not just installed, and that the service restarted.
- Check for compromise if you were exposed. The flaw is pre-authentication, so an internet-facing instance could have been hit before you patched. Review logs, rotate CI/CD secrets and tokens, and look for new users, runners, or scheduled jobs.
- Lock down access. Keep GitLab off the open internet where you can, and put it behind a VPN or allow-list so a future pre-auth flaw has a smaller window.
Must Read: JFrog Artifactory Vulnerability: Exploited in Three Days
Why a GitLab Flaw Is Worse Than It Looks
A self-managed GitLab server is rarely "just" a code host. It holds source code, CI/CD pipeline definitions, deployment credentials, and often tokens into cloud accounts and production. An unauthenticated attacker who runs code on that server is standing in the middle of your software supply chain, which is exactly the scenario CI/CD security controls are meant to contain.
That's why a pipeline compromise can do far more damage than a single application flaw. From a foothold on GitLab, an attacker can read secrets, tamper with builds, and push changes toward production, the same pattern behind major software supply chain attacks. Patching CVE-2026-110264 closes this specific door; treating your pipeline as production infrastructure keeps the next one smaller.
How OraSec Can Help
Patching GitLab is the urgent step; knowing what an attacker could reach through it is the next one. OraSec's vulnerability assessment and penetration testing checks whether your GitLab and the rest of your pipeline are reachable, confirms the fix held, and tests how far a foothold on CI/CD could spread into your cloud and production. If your instance was internet-facing before the patch, we can help confirm whether it was touched. The team's own research has produced published CVEs (CVE-2025-50847 through CVE-2025-50850).
Conclusion
CVE-2026-110264 is about as serious as a vulnerability gets: a perfect 10.0, no login required, and twelve years of releases exposed. If you run self-managed GitLab, upgrade to the fixed version for your line now, verify it's running, and check for compromise if the instance was exposed. Then treat the lesson as permanent: your Git server is production, and it deserves the same protection.
Frequently Asked Questions
Does the October 12 GitLab patch fix CVE-2026-110264?
No. The October 12 releases (19.2.8, 19.3.5, 19.4.2) fixed a different flaw, CVE-2026-97229. You still need the October 21 release for your line.
Is GitLab.com vulnerable?
No. GitLab's hosted service was already on a patched version. The risk is to self-managed Community and Enterprise Edition installs.
Is there a workaround if I can't patch yet?
GitLab's advisory lists no workaround, so upgrading is the only official fix. In the meantime, restrict network access to the instance as tightly as you can.
How far back does the flaw go?
To GitLab 7.0, released in 2014, about twelve years of releases. Lines older than 18.11 have no backported fix and must move to a supported line.
Was CVE-2026-110264 exploited in the wild?
At the time of writing it wasn't in CISA KEV and there were no confirmed attacks, but a reliable exploit for a closely related regex flaw already existed, so treat internet-facing instances as urgent.
