GitLab CVE-2026-110264: second CVSS 10 in ten days, patch again

Ten days ago we told self-managed GitLab owners to patch a perfect-10 regex bug. Do it again. GitLab CVE-2026-110264 is another CVSS 10.0 flaw that can let an unauthenticated attacker run code on your GitLab server, and it reaches back to version 7.0, released in 2014. The October 12 patch does not cover it.

What actually happened

GitLab's critical patch release 19.5.1, published October 21, describes CVE-2026-110264 as an integer overflow while compiling a specially crafted regular expression. Under "certain conditions" that GitLab does not spell out, an unauthenticated user could execute arbitrary code on the server. The CVSS 3.1 vector is the worst possible: network, low complexity, no privileges, no user interaction, scope change. Credit goes to joaxcar via HackerOne, the same researcher behind CVE-2026-97229.

Fixed versions: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. GitLab backported to the older branches outside its normal schedule, which tells you how seriously it takes this one. GitLab.com already runs the fix, and Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later are covered.

The Hacker News reports GitLab knows of no exploitation and that the bug was not in CISA's Known Exploited Vulnerabilities catalog as of October 22. There is no published workaround, so there is no config change that lets you skip the upgrade. GitLab did ship two detection rules, "Onigmo native worker crash" and "Org mode render error burst," for self-managed teams that want to check their logs.

Why it matters for your business

Patching once is not a patch program. Two critical regex bugs in ten days from one researcher means more are likely in the pipeline. If your upgrade process takes a weekend of planning, it is too slow for this cadence.

Plan for downtime on a single box. The 19.4.3 and 19.3.6 releases include database migrations. On a single-node install, GitLab will not start until they finish. Schedule a short window today rather than waiting for a quiet week that never comes.

Old branches are exposed too. Running 18.x because an upgrade broke something last year? You are affected, and 18.11.13 is your fix.

Our order: upgrade, then rotate CI/CD variables and runner tokens on any internet-facing instance, then run GitLab's two detection rules over recent logs.

Sources: GitLab Critical Patch Release 19.5.1, The Hacker News.