If you run your own GitLab server, update it this week

If your business runs its own GitLab server, update it this week, and ideally today. GitLab has fixed a flaw rated 10 out of 10 that, under certain conditions, could let someone with no login run their own code on your server.

If you use GitLab.com, you can stop reading. GitLab has already patched it for you.

What happened

On 21 October GitLab put out a critical patch release with new versions for every release line it still fixes: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. Both the free Community Edition and the paid Enterprise Edition are affected.

The release fixes twelve security problems. The one that matters most is tracked as CVE-2026-110264 and scored 10.0, the top of the scale. GitLab says it involves "compiling a specially crafted regular expression", and that it could let an unauthenticated user run code on the GitLab server.

In plain English: someone who has never logged in could send your server something nasty and end up running their own commands on it. GitLab doesn't say exactly what the "certain conditions" are, so I wouldn't count on your setup being the exception.

GitLab's page doesn't mention any attacks so far. It does say it "strongly recommend[s]" that every self-managed installation upgrades "immediately".

Why this one matters more than most

A GitLab server isn't just a place where code lives. It usually holds the keys to everything else: deploy passwords, cloud access tokens, database details stored as CI/CD variables, and SSH keys for the servers your code gets pushed to.

So someone running code on your GitLab server could be a short step away from your live website, your hosting account and your customer data. That's why I'd treat this as a today job rather than a next-month job.

There are two other fixes worth knowing about. One, rated 8.2, affects servers that sign people in with both SAML and LDAP auto-linking switched on. Another, rated 7.5, could let a stranger tamper with the sign-in setup if you use OAuth or OpenID Connect. Both are fixed by the same update.

Does it affect you?

You use GitLab.com. Nothing to do. GitLab says its own hosted service is already patched.

You're on GitLab Dedicated. GitLab says tenants on 19.3.5-internal0 or 19.4.2-internal0 and later already have the fixes.

You run GitLab yourself. On a server in the office, a virtual server you rent, or in Docker. This one's yours. The affected range for the critical flaw goes all the way back to version 7.0, so if you're running anything older than the versions listed above, you need to update.

A developer or agency set it up for you. Worth a quick message today to ask who's responsible for updating it. Self-hosted GitLab servers have a habit of being set up once and then forgotten about.

What to do this week

1. Check which version you're on. Signed in as an admin, the Help page in GitLab shows the version. On the server itself, if you installed GitLab from its Linux package, this command shows it near the top:

sudo gitlab-rake gitlab:env:info

2. Take a backup first. GitLab's documented command is:

sudo gitlab-backup create

GitLab's backup doesn't include /etc/gitlab/gitlab-secrets.json or /etc/gitlab/gitlab.rb, so copy those somewhere safe as well. Without the secrets file, a restored backup can't read some of its own data. The upgrade also takes its own database backup, but I'd still want my own copy.

3. Update. On Debian or Ubuntu with the Linux package, GitLab's upgrade guide gives:

sudo apt update && sudo apt install gitlab-ee

Use gitlab-ce instead if you're on the Community Edition. If you run it in Docker, change the image tag to a fixed version and recreate the container.

4. Watch out if you're well behind. If your server is several major versions old, you can't always jump straight to the latest one. GitLab's guide warns that some upgrade paths need multiple stops, where you install particular versions in order. Check the upgrade path before you start, not halfway through.

5. Plan for a short outage. GitLab says this release includes database changes, and a single-server install will be down while they run. Do it at a quiet time and tell your developers first.

6. Check it worked. Run the version check again and make sure the number matches one of the fixed versions.

The bigger point

Tools like GitLab are brilliant for small teams. They're free to run, and you keep your code on your own server. But "your own server" means updates are your job, and it's always the tool that sits quietly in the corner that gets missed.

If nobody in your business is going to keep an eye on releases like this one, that's what a support retainer is for. I keep your servers updated, take the backups before I touch anything, and tell you about it in plain English.