Tech Translated

IT Security & Technology Blog

Practical IT insights for Australian businesses. Our team covers cybersecurity advisories, compliance updates, and plain-English explainers on the technology your business relies on, published regularly as the landscape shifts.

GitLab Alert: patch now - critical unauthenticated remote code execution flaw CVE-2026-110264 in self-hosted GitLab

Critical GitLab Flaw Lets Attackers In Without a Password — Patch Now

If your business runs its own GitLab server — even one you forgot you had — stop and check it today. GitLab has just patched a maximum-severity flaw that lets an attacker run code on the server without logging in.

On 22 October, GitLab disclosed CVE-2026-110264, a flaw in the platform's regular expression compiler that allows an unauthenticated user to execute arbitrary code on a self-managed GitLab server. In plain terms: no username, no password, just a crafted request and the attacker is running commands on your box. GitLab rates it maximum severity and has shipped fixes across both the Community and Enterprise editions. It is the second serious GitLab bug this month, landing about ten days after a separate 10-out-of-10 flaw (CVE-2026-97229) in the same component.

Detail What it means
CVE-2026-110264 Maximum severity — unauthenticated remote code execution
Affected Self-managed GitLab CE & EE (GitLab.com is already patched)
Fixed in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13
Exposure Shadowserver tracks 2,700+ internet-facing GitLab CE instances

Why this matters for Australian businesses

"We don't run GitLab" is the answer we hear most often — and it's wrong more than people think. GitLab gets stood up for a single project: a client portal, an internal booking tool, a custom integration. The developer hands it over, the project wraps, and the server keeps running in a corner with nobody patching it. For wealth managers and not-for-profits who commissioned a portal to keep client data onshore, that quiet little server can be holding exactly the data you were trying to protect.

Across the client environments we pick up around the Northern Beaches and Central West NSW, forgotten developer infrastructure is one of the most common blind spots we find. An unauthenticated bug makes it worse, because the usual comfort of "it's behind a login" simply doesn't apply. With thousands of these servers sitting on the public internet, attackers don't need to know your business exists — scanners find the port for them.

"The dangerous GitLab server isn't the one your dev team manages. It's the one from a project two years ago that nobody remembers signing off."

Dan Briggs, All IT Services

What to do about it

  • Find out if you run GitLab at all. Ask your developer or IT provider whether any self-hosted GitLab exists from past or current projects.
  • Upgrade immediately to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, matching your version line.
  • Check if it's internet-exposed. If the login page is reachable from outside your network, treat patching as urgent and consider putting it behind a VPN.
  • Review recent activity on the server for anything unexpected, since the flaw needs no credentials to exploit.
All IT Cybersecurity services: we map what's actually running in your environment — including the servers nobody remembers — so a critical patch like this gets handled before it becomes a breach.
Why the urgency: unauthenticated means there's no login standing between an attacker and your server. These flaws get mass-scanned within days of disclosure, so "we'll do it next month" is a gamble.
Sources GitLab warns of new max severity code execution vulnerability, BleepingComputer, 22 October 2026

Written by Dan Briggs, All IT Services. All IT is a Sydney-based managed IT provider supporting small and medium businesses across the Northern Beaches, wider Sydney, Central West NSW, Brisbane and Melbourne.


Frequently Asked Questions

It is a maximum-severity vulnerability in GitLab's regular expression compiler, disclosed on 22 October 2026. It lets an unauthenticated attacker run their own code on a self-managed GitLab server. GitLab has released fixes for both the Community and Enterprise editions.
GitLab.com is already running a patched version, so cloud-hosted projects are covered. The risk is for self-managed installs that your own business or developer runs on a server or VM. Those need to be upgraded manually.
Yes, more often than people expect. GitLab gets stood up for a client portal build, an internal tool, or a one-off project and then quietly keeps running. If your business has ever paid for custom software or a web app, it is worth asking your developer or MSP whether a GitLab server is involved.
Upgrade to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, matching your release line. Because the flaw needs no login, an internet-exposed GitLab should be patched as a priority, not left for the next maintenance window.

Not sure what servers your business actually runs?

If you can't say for certain whether a forgotten GitLab or dev server is sitting on your network, let's find out together — before someone else does.


Related Guide

Cybersecurity for Sydney SMBs

Explore our complete guide to protecting your business from cyber threats.

Read the Full Guide →