GitLab has issued urgent fixes for a maximum-severity flaw that could allow an unauthenticated attacker to run code on a vulnerable self-managed server.
What is the issue?
The vulnerability, tracked as CVE-2026-110264, is an integer-overflow flaw in GitLab’s regular-expression compiler. Under specific conditions, a specially crafted expression could lead to remote code execution without the attacker first signing in.
Remote code execution is particularly serious because it can give an attacker a route into the GitLab server, its repositories, CI/CD configuration, deployment credentials, and other connected systems.
Which versions contain the fix?
GitLab says the issue is fixed in versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13. Administrators should move to the latest supported fixed release for their branch rather than treating those version numbers as a reason to delay a wider upgrade.
GitLab.com has already been patched. The warning is most relevant to organisations operating self-managed GitLab CE or EE installations.
What administrators should do
- Identify every GitLab instance. Include development, test, disaster-recovery, and internet-facing systems.
- Check the running version. Compare it with GitLab’s official patch release notice and upgrade promptly.
- Back up before the change. Protect the database, repositories, configuration, and secrets, and confirm the recovery procedure.
- Review exposure and logs. Look for unusual requests, new accounts, altered runners, unexpected pipeline changes, and unexplained processes.
- Rotate secrets if compromise is suspected. CI/CD variables, deploy keys, access tokens, and connected cloud credentials may all require attention.
Our advice
Do not leave a self-managed GitLab server exposed while waiting for a routine maintenance window. Patch first, then review whether the service needs to be reachable from the public internet and whether administrative access can be restricted through a VPN or trusted network.
