What the GitLab release of October 2026 fixes
On October 21, 2026, GitLab released a critical patch for its Community and Enterprise editions. CVE-2026-110264 is an integer overflow in the regular expression compiler: according to the advisory, an unauthenticated user could execute arbitrary code on the GitLab server. The CVSS 3.1 vector reported by a secondary source is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, meaning network exposure, no authentication, no user interaction. Affected versions run from 7.0 up to the fixed version of each branch.
Several flaws are circulating around GitLab's regular expression engine right now, and they are easy to mix up. CVE-2026-97229, fixed on October 12, 2026 in versions 19.4.2, 19.3.5 and 19.2.8, targeted the regex compiler for CI/CD configurations. Those three versions remain vulnerable to CVE-2026-110264. CVE-2026-85706, an already exploited path traversal, is a different matter, covered in our article on the emergency patch or the move to Gitea. Note that the version 19.3.2 it cites as fixed is itself vulnerable to CVE-2026-110264, since the 19.3 branch is only protected from 19.3.6. The same release fixes eleven other flaws, from high to low severity: they also justify the upgrade, but they do not change the procedure.
Which version to install for your branch
Scroll the table
| Your branch | Status | Version to install |
|---|---|---|
| 19.5.x | Affected before 19.5.1 | 19.5.1 |
| 19.4.x | Affected before 19.4.3, including 19.4.2 | 19.4.3 |
| 19.3.x | Affected before 19.3.6, including 19.3.5 | 19.3.6 |
| 19.2.x | Affected before 19.2.9, including 19.2.8 | 19.2.9 |
| 19.1.x | Affected before 19.1.9 | 19.1.9 |
| 19.0.x | Affected before 19.0.10 | 19.0.10 |
| 18.11.x | Affected before 18.11.13 | 18.11.13 |
| Any version older than 18.11 | Affected, the range starts at 7.0 | Follow the official upgrade path to a fixed branch |
Are you exposed: the reading that settles it
The question is not whether your instance is important, but whether it is self-managed and below the fixed version of its branch. GitLab.com is already fixed, and GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later already carry the fixes. For any installation you administer yourself, on a VPS or a dedicated server, the answer is simple: check the version number and compare it with the table above. An instance on 19.4.2 often assumes it is up to date because it received the October 12 fix. It is not.
The advisory names no configuration that would disable the flaw. An instance reachable from the Internet is obviously the most urgent, but an internal instance is not out of reach of a compromised workstation on the network. At the time of writing, GitLab reports no exploitation of CVE-2026-110264 and, according to the sources consulted, the flaw is not in the CISA catalog of exploited vulnerabilities. That is a window to act calmly, not a reason to postpone.
Check your version and prepare the window
Read the exact version
In the interface, the help menu shows the version. On the command line:
sudo gitlab-rake gitlab:env:info. On Docker:docker exec gitlab cat /opt/gitlab/version-manifest.txt. Write down the full number, not just the branch.Identify the installed edition
dpkg -l | grep gitlabon Debian and Ubuntu,rpm -q gitlab-ce gitlab-eeon RHEL and AlmaLinux. The package name,gitlab-ceorgitlab-ee, decides the upgrade command. Both editions are affected.Check the upgrade path
Jump straight to the fixed version only if no intermediate stop is required. GitLab states that you cannot upgrade directly to the latest major version when the path requires stops. In that case, install each stop with its exact number. The upgrade path tool in the official documentation gives the list.
Check disk space
df -h /var/opt/gitlab. The backup archive and the migrations need room. An almost full partition is the first cause of an upgrade interrupted halfway.Announce the outage
On a single node, GitLab warns that migrations must finish before startup: downtime is expected. Warn your teams, let running pipelines finish and note the state of the runners with
sudo gitlab-ctl status.Keep an exit route
Keep a second SSH session open and the current version number at hand. If a stop fails, you will know exactly which version to return to and which archive to restore.
Back up first, and know what the backup leaves out
The package backs up the database automatically before installing a newer version. GitLab still recommends keeping your own full, up-to-date backup, and you should not disable that automatic step (the empty file /etc/gitlab/skip-auto-backup exists for that). The command is sudo gitlab-backup create, or docker exec -t gitlab gitlab-backup create for a container named gitlab. The archive is a single .tar file, placed locally by the backup_path setting.
The classic trap: this backup does not contain the configuration. Copy /etc/gitlab/gitlab-secrets.json and /etc/gitlab/gitlab.rb separately, for example with sudo mkdir -p /root/gitlab-config-backup && sudo cp -a /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /root/gitlab-config-backup/. Without gitlab-secrets.json, a restore leaves encrypted data unreadable, such as CI/CD variables and two-factor authentication secrets. Then move both copies off the machine, to separate storage. A rollback is only possible with a database backup taken on the same version and edition as the one you restore to.
Upgrade according to your installation
Debian and Ubuntu (Omnibus package)
sudo apt update && sudo apt install gitlab-ce=<version>-ce.0
Replace<version>with the version from the table for your branch. For the Enterprise edition:sudo apt install gitlab-ee=<version>-ee.0.RHEL, AlmaLinux and Oracle Linux
sudo dnf install gitlab-ce-<version>-ce.0.el9
Use.el8on a version 8 machine, andgitlab-ee-<version>-ee.0.el9for the Enterprise edition.Docker with docker run
sudo docker stop gitlabsudo docker rm gitlabsudo docker pull gitlab/gitlab-ce:<version>-ce.0
Then rundocker runagain with exactly your original options: same ports, same volumes forconfig,logsanddata, same--shm-size. The data lives in the volumes, not in the deleted container.Docker with Compose
Edit the image tag in
docker-compose.ymlto target<version>-ce.0, then:docker compose pulldocker compose up -ddocker compose logs -f gitlab
If your file uses a floating tag, pin it: a pinned version makes the next upgrade readable.Apply the configuration
On Docker, GitLab reconfigures and upgrades itself on the container's first start. On a package install, after any change to
gitlab.rb, apply it withsudo gitlab-ctl reconfigure. Let the migrations run to completion before deciding the instance is stuck.Check the result
sudo gitlab-ctl statussudo gitlab-rake gitlab:env:info
The displayed version must match the table. Open the interface, check that a repository clones, that a pipeline starts and that the runners reconnect.
Rehearse on a copy when the instance is critical
Restore the backup on a disposable machine of the same version, upgrade it, then time the migrations. You get the real length of the outage and discover surprises without touching production. Destroy the copy afterwards: it holds your secrets.
Downtime, migrations, old upgrade paths: the three fears
Upgrading a production forge is frightening for precise reasons, and the GitLab advisory answers them plainly. Database migrations: the release includes some, regular ones in 19.4.3 and 19.3.6, and post-deploy ones in 19.4.3. Downtime: on a single node it is expected, since migrations must finish before startup; on multiple nodes, zero-downtime upgrade procedures apply. Old versions: below 18.11, follow the official upgrade path, stop by stop, without skipping a step.
What you do not lose, provided the backup exists: your repositories, your issues, your registered runners and your tokens. The fear of breaking everything is legitimate, but waiting is the riskier bet, because the technical detail of the flaw is due to become public on the issue tracker 90 days after the patch release. Better to upgrade before that day.
While the window is being prepared: reduce exposure, without illusions
- No official workaround — the GitLab advisory lists no mitigation: the only one is the upgrade.
- Restrict network access — limiting the instance to your VPN or an address list reduces the possible attackers. It is not an official measure, only a stopgap.
- Do not invent a filtering rule — no published nginx filter covers this flaw: writing one from memory gives a false sense of protection.
- Monitor now — apply the two detection rules published by GitLab, presented below, to learn whether someone has already tried something.
- Set a deadline — write down an upgrade date for the team: a stopgap without a date becomes a habit.
Check for traces after the upgrade
Apply the two detection rules
GitLab publishes two rules for self-managed instances: "Onigmo native worker crash" and "Org mode render error burst". Take them from the official advisory into your monitoring or log tool.
Read GitLab's logs
sudo ls -la /var/log/gitlabthensudo gitlab-ctl tail. Look for repeated worker process crashes and rendering errors concentrated over a short period, around or before October 21.Check accounts and tokens
In the admin area, review recent users, administrators, personal access tokens and deploy keys. Anything without a known author deserves an explanation.
Check runners and projects
List the registered runners and the webhooks. An unknown runner or a recently added hook is a classic entry point after a takeover.
Keep the logs
Copy the useful logs off the machine before letting them rotate. If a doubt appears in a week, you will have something to compare against.
If doubt remains: treat the instance as compromised
The absence of an alert does not prove the absence of a compromise: GitLab's two rules detect symptoms, not every intrusion. If a sign appears (a detection rule firing, an unknown account or runner, clustered crashes), treat the instance as compromised. Without a sign, exposure alone justifies the upgrade, not rotating every secret. If there is a sign, renew the instance secrets, the CI/CD variables, the runner tokens and the access tokens, and register the runners again. A pipeline variable that holds a deploy key or a database password must be changed at the source, not only in GitLab. It is tedious, and it is the price of a forge that holds your code and your production access.
Troubleshooting: common blockers
E: Version '<version>-ce.0' for 'gitlab-ce' was not found— apt does not know this number yet: runsudo apt updateagain, check that the GitLab repository is configured, then check the spelling of the number and the-ce.0suffix.- Cannot jump straight to the target version — your instance requires stops. Install them one by one with their exact number and let the migrations finish between two.
- 502 error page right after the upgrade — migrations are still running. Wait, follow
sudo gitlab-ctl tailand do not restart services by hand until they are done. - Container started but empty —
docker runwas run again without the original volumes. Stop it and recreate it with the same paths forconfig,logsanddata. - Restore fails after a rollback — the backup must come from the same version and the same edition. Restore with the version that produced it, then upgrade again.
A forge on a VPS: what changes
When your forge runs on a VPS where you have root, you decide the upgrade window, the backup location and how long logs are kept. Nobody imposes a schedule on you, and nobody upgrades on your behalf: that is the other side of the deal. Plan disk space for the archive, a copy off the machine, and a way to test a restore, as described in our guide on backups with restic. To install GitLab, our guide to installing GitLab CE on a VPS gives the starting point. If you would rather delegate server administration, the VPS administration option exists; this guide is provided as is, without support for your instance.
Official documentation
GitLab 19.5.1 patch release advisory: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
October 12, 2026 advisory: https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-4-2-released/
Upgrading a Linux package: https://docs.gitlab.com/update/package/
Upgrading a Docker installation: https://docs.gitlab.com/install/docker/upgrade/
Backing up GitLab: https://docs.gitlab.com/administration/backup_restore/backup_gitlab/
BleepingComputer report: https://www.bleepingcomputer.com/news/security/gitlab-warns-of-new-max-severity-code-execution-vulnerability/
