On October 21, 2026 GitLab released versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, fixing a critical vulnerability, CVE-2026-110264. It has the maximum CVSS score of 10.0: the attack works over the network, without authentication or user interaction. GitLab strongly recommends upgrading all installations immediately.
What happened
The bug is an integer overflow in the regular expression compiler. Every GitLab Community Edition and Enterprise Edition version from 7.0 onwards is affected, which means almost any self-managed GitLab that has not been upgraded to the new releases. GitLab offers no workaround. The vulnerability was found by researcher joaxcar and reported through HackerOne.
The same release fixes two more vulnerabilities: CVE-2026-15723 (CVSS 8.2) and CVE-2026-112212 (CVSS 7.5).
Who is at risk
- Self-managed GitLab: your own server, Omnibus, Docker or the Helm chart on Kubernetes. You have to upgrade it yourself.
- GitLab.com and GitLab Dedicated are already patched, and their customers do not need to do anything.
There are no reports of attacks on this vulnerability yet, and as of October 22 it is not in the CISA KEV catalog. But GitLab holds source code, CI/CD variables, deploy keys and production access, so a vulnerability rated 10.0 is worth closing before the first attacks appear.
What to do now
- Check your version:
Admin → Overview → Dashboard, or/helpas an administrator. - Upgrade to the fixed version of your branch: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. Branches older than 18.11 get no fix and have to move to a supported version along GitLab's upgrade path.
- Plan for downtime: 19.4.3 and 19.3.6 include database changes, so a single-node installation will be unavailable during the upgrade. Multi-node installations can be upgraded without downtime by following GitLab's guide.
- Take a backup before the upgrade (
gitlab-backup createplusgitlab-secrets.jsonandgitlab.rb), and afterwards check that runners, webhooks and pipelines work.
How to spot an attack
GitLab lists signs to look for in the logs: Onigmo native worker crashes and bursts of Org mode render errors. If they show up in logs from before the upgrade, check the server for signs of compromise and rotate CI/CD tokens and secrets.
We maintain self-managed GitLab and CI/CD for our clients' projects. We will upgrade GitLab along a safe version path with a backup and a rollback plan, check runners and pipelines, and if a compromise is suspected, inspect the server and rotate secrets.