GitLab shipped an emergency patch on 21 October for a flaw that lets an unauthenticated attacker run code on a self-managed GitLab server. The CVSS score is 10.0, the maximum, and the affected range reaches back to version 7.0 from 2014.
What happened
The bug is tracked as CVE-2026-110264 and sits in the regular expression compiler: an integer overflow (CWE-190) occurs when a specially crafted regex is compiled. Under conditions GitLab has not detailed, that is enough for an unauthenticated user to execute arbitrary code on the server.
GitLab rated it 10.0 with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H - network reachable, no privileges, no user interaction, and full impact beyond the vulnerable component. Fixes landed in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. The fixes were backported to 18.11 and the 19.0 to 19.2 lines specifically because of this issue.
GitLab.com and GitLab Dedicated are already patched. Only self-managed installations need to act. GitLab has also published two detection rules for exploitation attempts, built around an Onigmo native worker crash and bursts of Org mode render errors. No exploitation in the wild has been reported, and the flaw is not in CISA's known exploited vulnerabilities catalog.
Who is affected
Any self-managed GitLab Community or Enterprise Edition instance that is not on one of the fixed builds:
- All versions from 7.0 before 18.11.13, and 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.
- Instances upgraded in the 12 October patch round are still in range unless they are on the new builds, because those fixes sat one release below where the backports now land.
- Teams running GitLab on their own hardware or VM - software houses, integrators and MSPs with internal repos - rather than on GitLab.com.
What to do now
Upgrade to 19.5.1, or to the backport that matches your release track, before the end of the week. Treat this as a same-day change if your instance answers on a public IP.
- Check the running version under Help, or with
gitlab-rake gitlab:env:info, and confirm it against the fixed list above. - Plan for downtime: this patch carries database migrations on 19.4.3 and 19.3.6, so a single-node instance will be unavailable while they run. Multi-node setups can follow the zero-downtime procedure.
- Take the instance off the public internet if it does not have to be there. Put it behind VPN or an authenticating reverse proxy, so an unauthenticated pre-auth bug is not reachable by a scanner.
- Deploy GitLab's two detection rules and review the period since 21 October for unexpected admin users, new personal access tokens, added SSH keys, and changes to CI variables or runners.
- If anything looks off, rotate CI/CD secrets, deploy keys and any cloud credentials stored in pipeline variables - they are the reason an attacker would want this box.
What this means for South African businesses
Most South African SMEs do not run GitLab, so this is not a mass-market story here. The exposure sits with the software teams and integrators that self-host it, and those teams usually leave it reachable so that remote developers and contractors can push code. My read is that the real loss is not the GitLab server: it is the pipeline credentials, deployment keys and source history sitting behind it, which is exactly what a quiet attacker would take before anyone notices a crash.
Source: GitLab critical patch release, 19.5.1 and backports, 21 October 2026.
Also on the blog
Next step: If this is on your network or a client's, ask Matthews Enterprises to check exposure.