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 ServicesWhat 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.
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
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 →
