GitLab patched CVE-2026-110264 on 21 October. It is scored 10.0, the top of the CVSS scale, with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

In GitLab's own description, the flaw "could have allowed an unauthenticated user to execute arbitrary code on the GitLab server". The cause is an integer overflow when GitLab compiles a specially crafted regular expression.

The range starts at 7.0

The affected versions are every Community and Enterprise Edition release from 7.0 up to the fixed ones. GitLab 7.0 is from 2014.

That is twelve years of releases carrying the same defect, which tells you something specific rather than something embarrassing: the bug is not in the application code that has been rewritten several times over in that span. It is in the part underneath, where a regular expression is turned into something executable. Independent analyses place it in the regex engine GitLab bundles rather than in GitLab's own Rails code. GitLab's note does not name the component.

Code that old and that central is exactly where this kind of thing survives, and a counter in OpenBSD that had been wrong since 1988 made the same point this month. Age is not a measure of safety. It is a measure of how long nobody looked.

Ten point zero, and "only under certain conditions"

A 10.0 means unauthenticated, network-reachable, low complexity, and a scope change — the attacker breaks out of the component into the system around it. There is no higher score.

GitLab also says the overflow occurs only under certain conditions, and does not say which. Those two statements sit awkwardly together, and the gap between them is where an exploit either exists or does not. Nobody outside GitLab can close it from the published material.

What is published: no confirmed exploitation, no public proof of concept, and no CISA listing as of this morning. The flaw was reported through GitLab's HackerOne programme by a researcher working the bug bounty, which is the disclosure path that tends to come with a patch rather than with victims.

GitLab.com was already patched

GitLab says its own infrastructure, including GitLab.com and GitLab Dedicated, "remains patched". The exposure is self-managed installations, and the fix went out across 7 branches at once: 19.5.1, 19.4.3 and 19.3.6 on schedule, plus 18.11.13, 19.0.10, 19.1.9 and 19.2.9 backported outside it. A vendor patching 4 extra branches unscheduled is one that does not want anybody left with an excuse.

That split matters more than it reads. The organisations running GitLab themselves are often the ones that chose self-hosting for control or for regulatory reasons, which correlates with source code, deployment credentials and CI runners living on the same box.

What sits on a self-managed GitLab

Worth being concrete about what an unauthenticated remote code execution means on this particular machine, because it is not an ordinary web server.

A GitLab instance holds the source for everything the organisation builds, the CI configuration that deploys it, the runner tokens that execute that configuration, the container registry those runners push to, and very often the deployment credentials for production. It is also, by design, the system every developer trusts without thinking.

Code execution there is not a foothold in the network. It is the build pipeline, which is the thing an attacker wants a foothold in order to reach. The LiteLLM compromise this week was a demonstration of what happens when a build environment produces an artefact nobody checks.

What to do

  • Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, whichever matches your branch.
  • If your instance is reachable from the internet, treat this as the week's first job. The vector requires no account.
  • If it is internal only, you have more time and not unlimited time. Unauthenticated means any device on the network that can reach the port.
  • Check whether anything in front of GitLab accepts user-supplied patterns for search or filtering, and keep those logs while you upgrade.
  • If you cannot upgrade immediately, restrict network access to the instance rather than relying on authentication, because authentication is not in the path.

What is not established

  • Which conditions trigger the overflow. GitLab says only that there are some.
  • Whether a working exploit exists. None is public and GitLab does not say whether one was demonstrated.
  • Whether anyone has been attacked through it. No exploitation has been reported.
  • Which bundled component is at fault. Secondary analyses name one; GitLab does not.
  • Why the flaw was scored 10.0 if the conditions are narrow, since the vector published alongside it describes no preconditions at all.
  • How many self-managed instances are reachable from the internet. No count has been published.