GitLab has released patches for CVE-2026-110264, a maximum-severity flaw (CVSS 10.0) that lets an attacker with no credentials run code on self-hosted GitLab servers. GitLab.com is not affected. If your company or your IT provider runs its own GitLab, update to a fixed version today, even if you applied the 12 October patch.
The essentials
- CVE-2026-110264, CVSS 10.0. It is an integer overflow in GitLab's regular expression compiler. According to GitLab, under certain conditions it allows an unauthenticated user to execute arbitrary code on the server. Patches shipped on 21 October (BleepingComputer).
- Fixed GitLab CE and EE versions: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13.
- Scope: according to The Hacker News, it affects every self-hosted version since 7.0, released in 2014.
- The 12 October patch is not enough. It fixed CVE-2026-97229 (also CVSS 10.0) and only covered 19.2 and later. Anyone who updated then is still vulnerable.
- No known attacks. GitLab has not seen exploitation and CISA had not added it to its KEV catalogue as of 22 October. Spain's INCIBE-CERT and CCN-CERT published it on 22 October.
Am I affected if I use GitLab.com or GitLab Dedicated?
No. GitLab.com already runs the patched version. GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0, or later, already include the fix. The problem lies with self-managed GitLab CE or EE installs: the ones on your own server, in your cloud, or in a provider's that manages it for you.
I patched on 12 October. Am I not covered?
No. That patch fixed a different flaw from the same family, in the same regular expression engine. This one is new. According to The Hacker News, it is the fourth code execution flaw in that engine reported by the same researcher (alias joaxcar) in a month. You need to update again.
There is no shortcut either. GitLab has not explained what conditions are needed to exploit it and offers no temporary mitigation. Only updating protects you for certain.
What if my version is very old?
GitLab's usual policy only covers the current version and the two before it (19.5, 19.4 and 19.3). This time there are patches back to the 18.11 branch. If you are on a version older than any of the fixed branches, there is no patch for you: you must jump to a supported version.
What to do today
- Find out whether you run your own GitLab. Ask your tech team or your IT provider. Think code, CI/CD and client repositories.
- Check the version each instance is running.
- Restrict access while you prepare the update: VPN only, or an IP allowlist. There is no official mitigation, so limiting who can reach the server is all you have.
- Update to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, depending on your branch. If you are below those, jump to a supported version.
- Review the logs for unusual activity. If in doubt, rotate CI/CD tokens and secrets.
- If a third party manages your GitLab (agency, consultancy or hosting provider), ask them for written confirmation that it is patched.
What it means for a small business
A GitLab server is not just another tool. It holds your code, your clients' code and, above all, your CI/CD secrets: cloud credentials, deployment keys, production access. Whoever runs code there has a door to almost everything else.
No known attacks is no reason to wait. A CVSS 10.0 flaw, with no credentials needed and no temporary mitigation, is exactly the kind that gets exploited as soon as someone publishes the details.
The deeper lesson is different. Four code execution flaws in the same engine in a month suggest more are coming. Patching once and forgetting about it does not work. If you run your own GitLab, you need someone who watches the advisories and updates within days, not weeks. And it is worth asking two questions: does it really need to be exposed to the internet? Is it worth maintaining compared with GitLab.com or GitLab Dedicated, where this time you had nothing to do? If it is unclear who answers those questions in your company, this is a good moment to sort it out with cybersecurity support.
Frequently asked questions
Is there a setting that protects me without updating?
No. GitLab offers no temporary mitigation. Limiting access via VPN or an IP allowlist reduces exposure while you update, but only the patch protects you for certain.
Is it already being exploited?
GitLab has not detected attacks, and CISA had not added it to its catalogue of exploited vulnerabilities as of 22 October.
Do I need to do anything if I use GitLab.com?
No. GitLab.com is already patched, as is GitLab Dedicated on the versions listed above.
