On 21 October 2026 GitLab released a critical patch release that includes CVE-2026-110264, scored CVSS 10.0, the maximum. The flaw is in GitLab CE and EE and, under certain conditions, lets an unauthenticated user run arbitrary code on the GitLab server. The Hacker News has covered it too.
If you run a self-managed GitLab, update first and read the rest later.
Summary
| ID | CVE-2026-110264 |
| Score | 10.0 (Critical) |
| Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H |
| Weakness | Integer overflow in the regular expression compiler |
| Reporter | joaxcar, via GitLab’s HackerOne bug bounty |
The vector means: reachable over the network, low complexity, no login, no user interaction, with full impact on confidentiality, integrity and availability.
What is going on?
Per GitLab, the flaw is an integer overflow while compiling a specially crafted regular expression. According to The Hacker News, this happens in Onigmo, Ruby’s built-in regex engine, which GitLab ships and patches.
The worrying part: GitLab has not disclosed the exact conditions for exploitation, so for now no configuration setting lets you rule yourself out. Per the report there is no sign of active exploitation and, as of 22 October, it is not in CISA’s KEV catalog. That can change quickly.
What is affected?
Vulnerable: all versions from 7.0 up to these fixed releases:
| Branch | Vulnerable before | Fixed in |
|---|---|---|
| 19.5 | 19.5.1 | 19.5.1 |
| 19.4 | 19.4.3 | 19.4.3 |
| 19.3 | 19.3.6 | 19.3.6 |
| 19.2 | 19.2.9 | 19.2.9 |
| 19.1 | 19.1.9 | 19.1.9 |
| 19.0 | 19.0.10 | 19.0.10 |
| 7.0 to 18.11 | 18.11.13 | 18.11.13 |
GitLab.com is already patched, so only self-managed installs need action. GitLab Dedicated tenants on 19.3.5-internal0 and 19.4.2-internal0 or later are fixed too.
If you updated after 12 October to fix CVE-2026-97229 (also CVSS 10), The Hacker News reports those versions (19.2.8, 19.3.5 and 19.4.2) do not include this new fix, so you need to update again.
What to do
Update to the fixed release for your branch. GitLab offers no interim workaround; upgrading is the only certain protection.
Mind the migrations. 19.4.3 and 19.3.6 include database migrations. On a single-node instance the upgrade causes downtime, because migrations must finish before GitLab can start. Multi-node setups can use the zero-downtime procedure.
Restrict access until you update. If your instance is internet-facing and you cannot upgrade right away, temporarily limit access with a firewall, VPN or allowlist. This is not official GitLab guidance, just a general precaution.
Look for signs of compromise. GitLab published two detections for self-managed instances: “Onigmo native worker crash” and “Org mode render error burst”. Run them against your application logs (guide: Detecting security incidents). If the instance has been exposed, also check for unknown files, tokens and runners.
Rotate secrets if in doubt. GitLab usually has access to source code, secrets and CI, so if you suspect a breach, rotate tokens, CI variables and deploy keys.