GitLab has shipped an emergency critical patch release for CVE-2026-110264, an integer overflow in its regular-expression compiler that carries the maximum CVSS score of 10.0 and could let an unauthenticated attacker execute arbitrary code on a self-managed GitLab server. Released on October 21, 2026 as versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, the fix covers a flaw that reaches all the way back to GitLab 7.0. Censys counted roughly 82,000 internet-facing GitLab hosts on disclosure day, effectively all of them in range, and CERT-EU issued its own advisory urging organizations to patch and run a compromise assessment. Here’s what the bug does, who needs to act, and why this one should jump to the top of your change calendar.
The Flaw: A Regex That Breaks the Compiler
GitLab’s advisory describes the issue plainly: under certain conditions, an unauthenticated user could execute arbitrary code on the GitLab server “due to integer overflow when compiling a specially crafted regular expression.” Censys, summarizing GitLab’s published detection write-ups, places the bug in the renderer for Org-mode (.org) files, which passes a keyword from a #+TODO: line into a regular expression. The attack needs no login, only one public project that can hold the malicious .org payload.
Successful exploitation runs code as the git user, and that is about as bad as it gets for a source-control server. According to Censys, it exposes:
- Instance secrets: The contents of gitlab-secrets.json.
- CI/CD variables: Every variable stored on the instance, often including cloud and deployment credentials.
- Runner and access tokens: Keys that can pivot an attacker into build infrastructure.
- Every repository: Full read and write access, opening the door to code tampering and downstream supply-chain attacks.
Who Needs to Patch and How Fast
GitLab.com is already patched, and GitLab Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later need no action. Every self-managed Community and Enterprise Edition install, across all deployment types, is affected if it runs any of these versions:
- Legacy lines: 7.0 through 18.11.12 (fixed in 18.11.13).
- 19.0 to 19.2: Before 19.0.10, 19.1.9 and 19.2.9 respectively.
- Current lines: 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5.0 (fixed in 19.5.1).
As GitLab put it, “we strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately.” There is a catch for shops that have let upgrades slide. Censys estimates that more than half of internet-exposed GitLab servers run a release line more than seven months old that gets no fix of its own, and more than a quarter are three or more major versions behind. Those servers must step through GitLab’s required upgrade stops, which turns a quick patch into a multi-hop project, so start planning now.
It is also worth noting that this is GitLab’s second critical regex flaw in October. The October 12 release fixed CVE-2026-97229 in the CI/CD regular-expression compiler, and Censys points out that the versions shipped then (19.4.2, 19.3.5 and 19.2.8) are each below this new fix for their branch. Patching last week does not cover you this week.
Exploitation Status and Detection
The good news: as of October 22, the Censys Rapid Response team was not aware of in-the-wild exploitation, and CISA’s SSVC assessment on the NVD record listed exploitation as none. Censys also reported no working public proof-of-concept, noting that two GitHub repositories labeled with the CVE appeared and were either deleted or emptied. That window rarely stays open long for a CVSS 10 bug in a widely exposed product.
GitLab has published detection rules to help, and CERT-EU highlights them for compromise assessment. Practical checks for any instance that was reachable while unpatched include:
- Render error bursts: Repeated Org-mode render timeouts or regex worker crashes in GitLab logs.
- Odd child processes: Unexpected processes spawned by Puma, GitLab’s web server.
- Filesystem changes: New files owned by git in /tmp.
- Persistence: Changed crontabs or SSH keys for the git user.
Where those signs appear, GitLab’s guidance, as relayed by Censys, is to treat the instance as compromised and rotate its secrets.
The Rest of the Patch Bundle
The release also fixes two high-severity issues, an improper authentication flaw in OmniAuth-to-LDAP auto-linking email lookup and a cache poisoning issue in OAuth/OIDC discovery endpoints, plus five medium and four low severity bugs, according to GitLab and CERT-EU. Teams that rely on LDAP or SSO integrations have extra reason not to delay.
Looking Ahead
With full technical details for GitLab vulnerabilities published on its issue tracker 90 days after patching, and researchers already circling with lookalike repos, the safest assumption is that a working exploit will surface sooner rather than later. Expect CISA and national CERTs to escalate if exploitation is confirmed.
For IT teams, this is a reminder that self-hosted DevOps platforms are tier-one assets. Put internet-facing GitLab behind a VPN or identity-aware proxy where possible, keep instances within GitLab’s supported release lines so emergency patches are one hop instead of five, and treat CI/CD secrets as something to rotate on a schedule rather than only after a fire.
Sources:
- GitLab, October 21, 2026
- CERT-EU, October 22, 2026
- Censys, October 22, 2026
- InfoWorld, October 22, 2026
- The Hacker News, October 22, 2026
