GitLab patches a max-severity RCE flaw hiding in its regex compiler

On 22 October 2026, Bleeping Computer reported that GitLab had just released fixes for a maximum-severity flaw, tracked as CVE-2026-110264. This article relies on that one report, which itself draws on the vendor’s advisory, so keep that in mind as you read on.

A flaw in the regular expression compiler

According to Bleeping Computer, the bug lives in GitLab’s regular expression compiler. This background engine parses and validates the regexes found in configuration files. The culprit is an integer overflow: a calculation produces a number too big for the variable meant to hold it, and the program can then start handling memory in ways nobody planned for. There’s an old joke that if you solve a problem with a regex, you now have two problems. Here, the second problem is somebody else running code on your server.

According to the advisory quoted, an unauthenticated user could, under certain conditions, execute arbitrary code on the GitLab server. All they’d need to do is get it to compile a specially crafted regular expression. No account is required, and that’s what makes this kind of flaw so serious for an instance reachable from the internet. The attacker doesn’t even have to get past the login page.

A security researcher reported the flaw through GitLab’s bug bounty programme on HackerOne.

The versions that carry the fix

GitLab fixed the flaw in its Community (CE) and Enterprise (EE) editions, in versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. If your instance runs on one of those branches with a lower version number, it doesn’t have the fix. The vendor recommends upgrading any installation running an affected version to the latest release as soon as possible.

Two groups can put the kettle on and relax. GitLab.com already runs the patched version. GitLab Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or anything later have the fix too.

Why self-hosted can’t wait

On the managed service, the job is done. On a self-hosted instance, nobody is going to do it for you. Shadowserver, the threat-monitoring organisation, counts more than 2,700 GitLab Community Edition instances exposed online. It doesn’t say how many of them are honeypots or are already protected.

A recent precedent makes this more urgent. Last month, GitLab fixed CVE-2026-85706, another maximum-severity flaw that let an unauthenticated attacker read sensitive data on the server, including credentials. The next day, CISA, the US cybersecurity agency, added it to its list of actively exploited vulnerabilities and gave federal agencies three days to secure their systems. Since November 2021, CISA has flagged five exploited GitLab flaws, one of them in ransomware attacks. The source reports no exploitation of CVE-2026-110264 so far, though “so far” is carrying a lot of weight in that sentence.

The stakes go well beyond small hobbyist servers. According to Bleeping Computer, GitLab has more than 30 million registered users and is used by more than half of the Fortune 100.

A neighbouring flaw, ten days earlier

Ten days before this announcement, GitLab had already warned customers about another critical remote code execution flaw, CVE-2026-97229, rated 10 out of 10 on the CVSS base score. It affected the CI/CD regular expression compiler and was reported by the same researcher, who is clearly having a productive month. If you installed that patch, you’re still not covered against CVE-2026-110264. They are two separate CVEs, and each has its own fixed versions. It’s the same street, but a different break-in.

The fix is out. If your instance is exposed to the internet, “we’ll get to it next sprint” is not a patching strategy.