If your team runs its own GitLab server, this is a patch-today item. On 21 October 2026 GitLab released a critical patch release that fixes CVE-2026-110264, a flaw scored CVSS 10.0, the highest possible rating. GitLab says that under certain conditions it could have allowed an unauthenticated user to execute arbitrary code on the GitLab server.
This guide is for founders, CTOs and the people who maintain GitLab. It has no exploit detail.
What the flaw is
GitLab describes CVE-2026-110264 as an integer overflow that occurs when compiling a specially crafted regular expression. The component is the Regular Expression Compiler, an engine GitLab uses to parse and validate regular expressions in configuration files. A security researcher reported it through GitLab's HackerOne bug bounty program.
BleepingComputer reports that Shadowserver tracks more than 2,700 GitLab Community Edition instances exposed to the internet. It is unknown how many of those are honeypots or are already patched. It also reports that GitLab warned about another CVSS 10 flaw in the CI/CD Regular Expression Compiler (CVE-2026-97229) about ten days earlier, reported by the same researcher.
Who is affected
Affected are GitLab Community Edition and Enterprise Edition, all versions from 7.0 up to:
| Release line | Fixed version |
|---|---|
| 18.11 and earlier | 18.11.13 |
| 19.0 | 19.0.10 |
| 19.1 | 19.1.9 |
| 19.2 | 19.2.9 |
| 19.3 | 19.3.6 |
| 19.4 | 19.4.3 |
| 19.5 | 19.5.1 |
GitLab.com is already running the patched version. GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 or later already include the fixes. Only self-managed installations need action.
What to do this week
- Find every GitLab instance. Include old test servers, client-specific installs and anything a former vendor set up.
- Check the version under Help in the GitLab interface or with your package manager.
- Upgrade to the fixed version for your release line from the table above. If you are on an older line than 18.11, plan an upgrade path to a supported release.
- Plan for downtime. GitLab says this patch includes database migrations. Single-node instances will be down while migrations finish. Multi-node instances can use zero-downtime upgrade procedures.
- Restrict exposure while you plan. If the server does not need to be public, put it behind a VPN or an IP allowlist.
- Use GitLab's threat detections. GitLab has released two detections for self-managed instances to help spot exploitation attempts. Review the advisory for how to use them.
- Review logs and access. Look for unexpected logins, new users or tokens, and changes to CI/CD settings. If anything looks wrong, rotate project and runner secrets.
- Subscribe to GitLab's patch notifications so the next critical release does not depend on someone reading the news.
Server and runtime flaws like this sit below your application code, so they are fixed by updating the platform. We saw the same pattern in the PHP2Shell patch and the Node.js October 2026 security release. A website maintenance routine with scheduled updates keeps these from turning into emergencies.
Need help auditing or upgrading your GitLab, CI/CD or hosting setup? Talk to Susraj Tech.
Frequently asked questions
Which versions fix CVE-2026-110264?
18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1.
Do I need to act if I use GitLab.com?
No. GitLab.com is already patched.
Sources
- GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13
- BleepingComputer: GitLab warns of new max severity code execution vulnerability
Last reviewed 22 October 2026. This article is general security information, not a guarantee of protection. Details may change as GitLab publishes more information.
