Critical GitLab flaw may let attackers run code on the server without logging in

What happened

GitLab is a platform where companies store source code, manage projects and run automated builds and deployments (CI/CD). Many organizations run it on their own servers.

On October 21, 2026, GitLab released a critical patch for both Community Edition (CE) and Enterprise Edition (EE). The most serious fix, CVE-2026-110264, addresses a flaw that under certain conditions could let an attacker with no account run arbitrary code on the server. The bug sits in the regular expression compiler, the part that handles the patterns used to search text.

GitLab urges all self-managed installations to upgrade immediately. CERT-EU, the cybersecurity team of the EU institutions, published an advisory with the same recommendation on October 22, 2026. There are no confirmed reports of exploitation so far, but GitLab has released detection rules to help spot attack attempts.

Why it is dangerous

This is an integer overflow. Think of an old car odometer that rolls over from 999,999 back to zero. When GitLab compiles a specially crafted regular expression, a number the program relies on wraps around in a similar way, and the program carries on with a wrong value. Under certain conditions, an attacker can use this to run their own code on the server.

According to GitLab’s rating, the attack needs no login and no user interaction, and it works over the network. If your GitLab is reachable from the internet, anyone can try. An attacker who runs code on a GitLab server this way may reach your source code, the credentials stored in CI/CD and your deploy keys, and often other company systems too.

CVSS rates severity from 0 to 10, and GitLab scored this flaw 10.0, the maximum. EPSS estimates the chance of exploitation in the next 30 days. As of October 28, 2026, it is about 1%, higher than roughly 63% of known vulnerabilities. The CISA KEV catalog lists flaws with confirmed exploitation. This one is not listed yet, but that does not mean you are safe.

Who is affected

Self-managed installations of GitLab CE and EE are affected in these versions:

from 7.0 before 18.11.13
19.0 before 19.0.10
19.1 before 19.1.9
19.2 before 19.2.9
19.3 before 19.3.6
19.4 before 19.4.3
19.5 before 19.5.1

All deployment types are affected: Omnibus packages, source installs, Docker containers and the Helm chart. Typical examples are in-house servers of development teams, software vendors, schools and public authorities.

GitLab.com users are not affected, as it already runs the patched version. GitLab Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later already have the fix and do not need to do anything.

How to check if you are affected

The easiest way is to sign in as an administrator and open the Admin area. The version is shown right on the overview. You can also find it on the /help page of your instance.

On a server with the Omnibus package, these read-only commands show the version:

sudo gitlab-rake gitlab:env:info

sudo cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

For Docker (adjust the container name) and for Kubernetes with Helm:

docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

helm list -A | grep -i gitlab

Compare the result with the list of affected versions. Any version lower than 18.11.13 is affected. In the 19.0 to 19.5 lines, you are affected if your version is lower than the fixed release for your line. For Helm, look at the APP VERSION column.

How to fix it

The fixed versions are 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. Upgrade to the fixed release in your line, for example from 19.4 to 19.4.3. If you run an older line below 18.11.13, there is no fixed release for it. Upgrade to at least 18.11.13 and go through the required upgrade stops shown by the GitLab Upgrade Path tool.

Recommended order:

Start with servers reachable from the internet, as CERT-EU also advises.
Take a backup with sudo gitlab-backup create and also save /etc/gitlab/gitlab-secrets.json and /etc/gitlab/gitlab.rb. The regular backup does not include them.
For Omnibus on Debian or Ubuntu, run sudo apt-get update and then sudo apt-get install --only-upgrade gitlab-ee (or gitlab-ce). This installs the latest version. To stay in your line, name the exact version, for example sudo apt-get install gitlab-ee=19.4.3-ee.0.
For Docker, pull the image with the fixed version and recreate the container. For Helm, deploy the chart that ships the fixed GitLab version.
After upgrading, confirm the version the same way as in the check section.

GitLab’s advisory does not list any workaround, so upgrading is the only fix. Until you can patch, a general measure is to allow internet access to GitLab only through a VPN or from allowlisted IP addresses. This does not remove the flaw, though. The same release also fixes 11 other issues, 2 of them rated high.

What if you may already be compromised

GitLab has published two detection rules for exploitation attempts: “Onigmo native worker crash” and “Org mode render error burst”. Judging by their names, they watch for unexpected crashes of worker processes while handling regular expressions (Onigmo is a regular expression library) and sudden bursts of errors when rendering Org-format documents. CERT-EU recommends checking whether any server has been compromised and points to these rules for that assessment.

Where to look (these commands only read). The first one searches the Puma and Sidekiq logs, including older compressed files, for process crash entries (“Segmentation fault” or “[BUG]”). The second lists processes running as the git user.

sudo sh -c 'zgrep -iE "segmentation fault|\[BUG\]" /var/log/gitlab/puma/puma_stderr.log* /var/log/gitlab/puma/current /var/log/gitlab/sidekiq/current /var/log/gitlab/sidekiq/@*'

ps -u git -o pid,etime,cmd

Unknown admin accounts, new access tokens and SSH keys.
New runners, webhooks and deploy keys that nobody added.
Unknown processes running as the git user and unexpected outbound connections.

If you find suspicious traces, disconnect the server from the network, do not delete anything and bring in an incident response specialist. After a compromise, change every password, token and key stored in GitLab, including CI/CD variables.

Sources

Articles are put together by an AI agent from public sources (vendors, CISA, ENISA, NVD, SK-CERT, NÚKIB), and version numbers and CVEs are checked against them automatically. Always confirm the steps in the vendor advisory before touching production.