Update GitLab self-managed (CVE-2026-110264)
On 21 October 2026 GitLab patched CVE-2026-110264, a CVSS 10.0 flaw that allows unauthenticated code execution on the server and affects self-managed GitLab from version 7.0, released in 2014. Nine days earlier it had fixed CVE-2026-97229, also rated 10.0. GitLab.com is already updated; self-managed installations are up to you.
Do you have this vulnerability? We update your GitLab to the fixed version for your branch, plan the downtime if the database migrations require it, and review runners, tokens and logs.
$ sudo gitlab-rake gitlab:env:info | grep -A1 "GitLab information"GitLab informationVersion: 19.4.2-ee# 19.4.2 fixes CVE-2026-97229, not CVE-2026-110264$ cat /opt/gitlab/embedded/service/gitlab-rails/VERSION19.4.2-ee# Also in the browser: https://your-gitlab/helpFor the 19.4 branch: update to 19.4.3Two CVSS 10.0 flaws in nine days
If you updated on 12 October for CVE-2026-97229, you have to do it again: that fix does not cover CVE-2026-110264, which reaches every version since 2014.
CVE-2026-110264 is an integer overflow when compiling a crafted regular expression in Onigmo, the Ruby regex engine that GitLab bundles and patches in its own packages. GitLab has shipped it since 7.0, which is why the flaw goes back so far. GitLab has not explained what conditions an attacker needs, so you cannot rule yourself out by configuration, and it offers no temporary mitigation: the only fix is updating.
On 12 October GitLab had fixed CVE-2026-97229, also CVSS 10.0: unauthenticated code execution through a crafted regular expression in the CI/CD configuration, in versions 19.2 to 19.4 (fixed in 19.2.8, 19.3.5 and 19.4.2). A public proof of concept exists.
As of 22 October, GitLab reports no exploitation of CVE-2026-110264 and it is not in CISA’s KEV catalog. GitLab has published two Sigma rules to look for attempts, “Onigmo native worker crash” and “Org mode render error burst”. GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later already have the fix.
Sources: The Hacker News: CVE-2026-110264 · The Hacker News: CVE-2026-97229
Fixed GitLab versions
This applies to GitLab CE and EE that you install yourself (Omnibus, Docker, Helm). If your version is older than the one for its branch, you are affected by CVE-2026-110264.
| If you run | Update to | Note |
|---|---|---|
| 19.5 (before 19.5.1) | 19.5.1 | |
| 19.4 (before 19.4.3) | 19.4.3 | DB migrations: downtime on a single node |
| 19.3 (before 19.3.6) | 19.3.6 | DB migrations: downtime on a single node |
| 19.2 (before 19.2.9) | 19.2.9 | |
| 19.1 (before 19.1.9) | 19.1.9 | |
| 19.0 (before 19.0.10) | 19.0.10 | |
| 7.0 – 18.11 (before 18.11.13) | 18.11.13 | May require intermediate versions |
Check this
- You run GitLab CE or EE on your own server, in Docker or in your cloud, not on GitLab.com.
- The version shown at
/helpis older than the one for your branch in the table. - You updated on 12 October to 19.2.8, 19.3.5 or 19.4.2: you are still affected by CVE-2026-110264.
- You are on 18.10 or older: your target is 18.11.13 or a 19.x release, and GitLab requires intermediate stops along the upgrade path.
- Your instance is reachable from the internet, even with sign-ups closed: the flaw needs no account.
No temporary mitigation
GitLab offers no workaround for CVE-2026-110264. What you can prepare is the update itself, so it works the first time.
- 01 GitLab has not said what conditions are needed to exploit the flaw, so no configuration takes you out of scope.
- 02 On a single-node server, 19.4.3 and 19.3.6 run database migrations during the update, and GitLab is down until they finish.
- 03 With several nodes you can apply it without downtime by following GitLab’s zero-downtime procedure.
- 04 Before touching anything: back up the database and repositories, plus
gitlab-secrets.jsonandgitlab.rb, which the standard backup does not include.
Seven steps, in this order
We follow the same procedure on every server: first find out which version runs where, then fix it, and finally check that nobody got in before the patch.
Version inventory
We record version and edition (CE or EE), installation type (Omnibus, Docker, Helm), number of nodes, registered runners and where the instance can be reached from.
Immediate mitigation
With no official workaround, what can be done while the window is prepared is reducing who can reach the instance, for example keeping it behind the VPN only if your team can work that way.
Update
Backup, an upgrade path with the stops GitLab requires if you come from an old version, and the jump to the fixed version for your branch. If the migrations force downtime, we pick the moment with you.
Verification
We check the version at /help, that database migrations have finished, that runners connect and that pipelines pass again.
Review for indicators of compromise
We run GitLab’s published Sigma rules against the logs and review recently created users, personal access tokens and SSH keys.
Secret rotation, if needed
If there are indicators, we rotate runner tokens, personal and deploy tokens, CI/CD variables and the keys pipelines use to deploy.
Monitoring new advisories
We record the version, the upgrade path and GitLab’s patch calendar, so the next update does not start from scratch.
Why a GitLab update goes wrong
Has your GitLab gone years without an update?
Free consultation →CVE-2026-110264 FAQ
Which GitLab version fixes CVE-2026-110264?
I already updated on 12 October. Do I have to do it again?
I use GitLab.com. Do I need to do anything?
Will the update take GitLab down?
Is there any mitigation if I cannot update today?
Tell us which GitLab you run
With the version, installation type and number of nodes we can tell you the upgrade path and whether downtime will be needed.
Tell us your challenge. We'll propose a solution.
No commitment. Within 24 hours, you'll receive a proposal with scope, timeline and budget. No fine print.