---
title: "Self-hosting GitLab? A 10/10 flaw runs code without a login"
description: "On October 21, 2026, GitLab fixed CVE-2026-110264, a 10.0 flaw that reaches every version from 7.0. If you upgraded on October 12, you still need 19.5.1, 19.4.3 or the fixed release for your branch."
url: https://ihsanalapsi.dev/articles/gitlab-cvss-10-unauthenticated-rce
lang: en
date: 2026-10-23
updated: 2026-10-24
tags: ["Security updates", "App security"]
author: Ihsan Alapsi (إحسان العبسي)
---
# Self-hosting GitLab? A 10/10 flaw runs code without a login

If you run GitLab on your own server (self-managed), upgrade it today to the fixed release for your branch from October 21, 2026, even if you upgraded on October 12. The new flaw scores 10 out of 10, reaches every version from 7.0, and has no workaround. By the end of this article you'll know your version, the version you need, and how to upgrade without losing data.

## What is CVE-2026-110264?

CVE-2026-110264 is a flaw in GitLab CE and EE that lets a user who isn't logged in run code on the server under certain conditions, and GitLab hasn't explained what those conditions are. The cause is an integer overflow while compiling a specially crafted regular expression.

An integer overflow happens when a number grows past the space reserved for it in memory and wraps to a wrong value, and in code written in a language like C that mistake can lead to code execution. [GitLab's release page](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/) gives it a CVSS score of 10.0 with these values:


| Part        | Value   | What it means                                   |
| ----------- | ------- | ----------------------------------------------- |
| AV:N        | Network | The attack comes over the network               |
| AC:L        | Low     | No hard conditions needed                       |
| PR:N        | None    | The attacker needs no account                   |
| UI:N        | None    | Nobody on your team has to click anything       |
| S:C         | Changed | The impact goes beyond the vulnerable component |
| C:H/I:H/A:H | High    | Full read, change and shutdown                  |


The security table on the release page doesn't name the component, but the bug fix list on the same page has an item called Add Ruby regexp repeat ID overflow patch, and one of the two detection rules GitLab published is called Onigmo native worker crash. Onigmo is Ruby's default regular expression library since Ruby 2.0, according to [the project page](https://github.com/k-takata/Onigmo), and [The Hacker News coverage](https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html) names it as the affected component. The second rule is called Org mode render error burst, and GitLab hasn't said that Org mode files are the attack path. The flaw was reported by a researcher called joaxcar through HackerOne.

A GitLab server holds a company's code, its CI/CD secrets, and the tokens that deploy to production. Whoever runs code on it can read those secrets or change a project that gets built and deployed from it. The same risk comes up in [protecting GitHub Actions when someone changes an action's tag](/articles/github-actions-workflow-lockfiles): whoever can change the build pipeline can change the code that reaches production.

## Why isn't the October 12 update enough?

The October 12 update fixed a different flaw, CVE-2026-97229, in versions 19.4.2, 19.3.5 and 19.2.8. The new flaw is still present in those versions, because it affects 19.4 before 19.4.3, 19.3 before 19.3.6, and 19.2 before 19.2.9.

Both flaws score 10.0, and both are integer overflows in regular expression compiling, but they take different paths. According to [the October 12 release page](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/), CVE-2026-97229 goes through a regular expression inside the CI/CD configuration and only affected 19.2 to 19.4. CVE-2026-110264 affects every version from 7.0, which goes back to June 2014 according to [the version's tag in GitLab's repository](https://gitlab.com/gitlab-org/gitlab/-/tags/v7.0.0-ee).

GitLab released the fix on seven branches on the same day: the usual releases 19.5.1, 19.4.3 and 19.3.6, plus backports to the older 19.2, 19.1, 19.0 and 18.11 branches. If you felt safe because you're on an older version and the October 12 update didn't apply to you, this one does.

## Who needs to upgrade, and to which version?

Every GitLab CE or EE server you run yourself needs to upgrade to the fixed release for its branch. GitLab.com is already patched, and GitLab Dedicated customers on 19.3.5-internal0 or 19.4.2-internal0 or later have the fix.


| Your branch  | Fixed release |
| ------------ | ------------- |
| 19.5         | 19.5.1        |
| 19.4         | 19.4.3        |
| 19.3         | 19.3.6        |
| 19.2         | 19.2.9        |
| 19.1         | 19.1.9        |
| 19.0         | 19.0.10       |
| 7.0 to 18.11 | 18.11.13      |


The same release fixes 11 other flaws. The most serious is CVE-2026-15723 (high, 8.2): if you have both OmniAuth SAML and LDAP auto-linking enabled, a user with an account can take over an existing LDAP account without its owner doing anything. Its fix is only in 19.3.6, 19.4.3 and 19.5.1, so if you use that setup, the older releases in the table aren't enough for you.

## How do you find your GitLab version?

On a server installed with the official Linux package (Omnibus), the gitlab:env:info task prints a GitLab information section with a Version line showing your version. Compare it with the table above.

```bash
sudo gitlab-rake gitlab:env:info
```

The command comes from [the maintenance tasks documentation](https://docs.gitlab.com/administration/raketasks/maintenance/). In the docs' example the line reads `Version: 15.5.5-ee`. The number before the hyphen is what you compare with the table, because CE and EE share the same fixed releases. If your version is older than the fixed release for its branch in the table, your server is affected.

## How do you upgrade without losing anything?

Take a backup along with your configuration files, then upgrade to the fixed release for your branch. If your version is old, you have to pass through required upgrade stops before you get there.

Start with the backup. This command creates a backup file in GitLab's backup folder:

```bash
sudo gitlab-backup create
```

Then:

1. Copy the configuration files separately. [The backup documentation](https://docs.gitlab.com/administration/backup_restore/backup_gitlab/) says the backup command doesn't store configuration, and at minimum you must keep `/etc/gitlab/gitlab-secrets.json` and `/etc/gitlab/gitlab.rb`. The secrets file holds the database encryption key, and if you lose it, GitLab can't decrypt encrypted values such as CI/CD variables and two-factor authentication data.
2. Work out your upgrade path with [the Upgrade Path tool](https://gitlab-com.gitlab.io/support/toolbox/upgrade-path/). According to [the upgrade stops page](https://docs.gitlab.com/update/upgrade_paths/), the GitLab 18 stops are 18.2, 18.5, 18.8 and 18.11, and you should let background migrations finish at each stop before the next one. You get the list of versions you have to pass through.
3. Upgrade with your installation method. This release includes database migrations, so a single server is down until they finish. Multi-node setups can upgrade with no downtime using GitLab's zero-downtime upgrade procedure.
4. Run `sudo gitlab-rake gitlab:env:info` again and check that the Version line shows the fixed release.

## Is anyone exploiting the flaw right now?

As of October 23, 2026, there's no reported exploitation of CVE-2026-110264, and the flaw isn't in CISA's Known Exploited Vulnerabilities catalog.

The latest version of [the catalog](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) is 2026.10.23 and doesn't include the flaw, and The Hacker News reported that GitLab has seen no sign of exploitation. The release page itself says nothing about exploitation, but GitLab published the two detection rules above with it so you can watch your server. The same catalog lists 5 GitLab flaws that were exploited before, the latest being CVE-2026-85706, added on September 11, 2026.

## Where do you start now?

Run the version command on your server now, and if it's older than the table, take the backup and upgrade today. There's no workaround to lean on in the meantime.

After the upgrade, review admin accounts and new users. If you suspect someone got in before you upgraded, treat the CI/CD secrets stored in GitLab as exposed and rotate them in the order from [the Railway breach article](/articles/railway-breach-env-vars-rotate-secrets): databases first and deploy tokens last. And if you're upgrading your servers this month, also check [the NGINX flaws fixed in October](/articles/nginx-1-30-6-security-fixes).

If you want someone to test your platform from the outside the way an attacker sees it, that's what [Muhassan](/muhassan) does.

## FAQ

**I use GitLab.com. Do I need to do anything?**

No. GitLab wrote that GitLab.com is already patched. GitLab Dedicated customers on 19.3.5-internal0 or 19.4.2-internal0 or later have the fix too.

**I upgraded on October 12. Am I protected?**

No. The October 12 update (19.4.2, 19.3.5 and 19.2.8) fixed a different flaw, CVE-2026-97229. The new flaw exists in every 19.4 release before 19.4.3, so 19.4.2 is still affected, and you need the October 21 release.

**Is there a workaround if I can't upgrade today?**

No. The release page lists no workaround, so upgrading is the only protection GitLab offers. If you must wait a few hours, limit who can reach the GitLab interface over the network until you upgrade, but that doesn't replace the upgrade.

**Does the LDAP flaw in the same release affect me?**

Only if you have both OmniAuth SAML and LDAP auto-linking enabled. Its fix is in 19.3.6, 19.4.3 and 19.5.1, so if you use that setup and upgraded to 18.11.13, 19.0.10, 19.1.9 or 19.2.9, you still need 19.3.6 or later.

**How long is GitLab down during the upgrade?**

On a single server, GitLab is down until the database migrations finish, because this release includes migrations. Multi-node setups can upgrade with no downtime if they follow GitLab's zero-downtime upgrade procedure.