If you use GitLab.com, you can relax. GitLab has already patched its own hosted service. This one is about the server sitting in your office, in a cupboard, or on a cloud account somebody set up a few years ago and hasn't logged into since.
What's actually been fixed
The headline issue is CVE-2026-110264. GitLab describes it as an integer overflow when compiling a specially crafted regular expression. In plain English, a carefully built piece of input can break the code that handles pattern matching, and GitLab's advisory says that, under certain conditions, this "could have allowed an unauthenticated user to execute arbitrary code" on the server.
Unauthenticated is the important word. An attacker wouldn't need an account. If your GitLab server can be reached from the internet, that is about as bad as it gets, which is why it scores a perfect 10.
When The Register reported it on 22 October, there was no sign yet of anyone exploiting it in the wild. That's good news, but it isn't a reason to wait. Once a fix is public, the details are out there for anyone to study, and The Register expects scanning to start soon. I made the same point about PHP's critical flaw earlier this week in why "update now" means today, and the same logic applies here.
The same release also fixes ten other issues. Two are rated high: one can let a logged-in user take over an LDAP-backed account when SAML and LDAP auto-linking are both switched on, and another lets an unauthenticated user poison a shared cache so that sign-in flows redirect to an outside server. The rest are medium or low, but you get them all in the same upgrade, so there's no picking and choosing.
Which versions you need
GitLab has released fixes across seven supported lines. You want to be on one of these, or later:
- 19.5.1
- 19.4.3
- 19.3.6
- 19.2.9
- 19.1.9
- 19.0.10
- 18.11.13
If you're on anything older than 18.11, there's no patch for your version. You're on an unsupported release with a critical hole in it, and the only fix is to upgrade to a supported one.
How to check and upgrade without making things worse
First, find out what you've got. Log in as an admin and look at the Help page, or check the version on the server itself. It sounds obvious, but plenty of small firms have a GitLab box that one person set up and nobody else really knows about. If that's you, this is a good week to find out where it lives.
Second, take a backup and make sure you can actually restore it. GitLab upgrades usually go fine. "Usually" is doing a lot of work in that sentence, and you don't want to find out your backup was empty halfway through a failed migration.
Third, plan for a bit of downtime. GitLab's notes say single-node installs will be down while the database migrations finish, because GitLab won't start until they're done. If you run a multi-node setup, you can follow their zero-downtime process instead. For most small businesses, it's a single server, so pick a quiet hour and tell people.
Fourth, if you're a long way behind, don't try to jump straight to the latest version. GitLab has required upgrade stops, versions you have to pass through on the way. For GitLab 19 those are 19.2, 19.5, 19.8 and 19.11. GitLab's Upgrade Path tool will work out the route for you from your current version to your target. Skipping a stop is a reliable way to turn a half-hour job into a long evening.
Finally, GitLab Security has published two threat detections for self-managed instances that relate to this flaw, called "Onigmo native worker crash" and "Org mode render error burst". If you have logging and alerting in place, it's worth adding them, so you'd know if someone tried their luck before you patched.
Should it be on the internet at all?
This is the bigger question, and it's worth asking once the patch is done. A lot of self-hosted GitLab servers are open to the whole internet because that was the easiest way to let people work from home. It doesn't have to be. Putting it behind a VPN, or restricting access to known IP addresses, means the next unauthenticated bug is a much smaller problem for you.
It's also fair to ask whether you need to self-host at all. There are good reasons to: cost at scale, keeping code on your own infrastructure, or compliance. But if the honest answer is "someone set it up in 2019 and we've never thought about it since", then either somebody needs to own it properly, or it's worth weighing up a hosted option where the patching is someone else's job.
The real lesson
The pattern this week has been the same twice now. A widely used piece of open-source software gets a critical fix, and every business running it has a few days, at most, to get it applied. The firms that manage it calmly aren't necessarily the ones with big IT teams. They're the ones who know what they're running, where it is, and who's responsible for keeping it updated.
If you can't answer those three questions for your GitLab server, or for your other servers, that's the thing to fix. A simple list of every system, its version and who looks after it is dull to write. It's also the first thing you'll want next time.
That's the sort of work we do. Our Linux server management covers patching, monitoring and hardening for small businesses, and our outsourced tech department is for firms that want someone to own the whole lot, from servers to software, for a monthly fee.
If you've got a GitLab server you're not sure about, or you'd just like a second pair of eyes on the upgrade, drop us a line. We're happy to have a look.
Cheers, Rob
