GitLab released emergency security updates on October 21, 2026, for a critical flaw that could let an unauthenticated attacker run code on the server. Its advisory identifies CVE-2026-110264 as an integer-overflow vulnerability involving regular expressions and urges self-managed operators to upgrade immediately.
A successful attack may leave no crash, according to GitLab's detection guidance. That limits what operators can learn from apparently clean logs while they assess an exposed instance.
Check the fixed branch, then the upgrade path
The release notice lists these fixed versions for Community Edition and Enterprise Edition:
| Release line | Fixed version |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 | 19.2.9 |
| 19.1 | 19.1.9 |
| 19.0 | 19.0.10 |
| 18.11 | 18.11.13 |
The affected range starts at GitLab 7.0. GitLab.com is already patched. The same notice backports this critical fix to older branches, but lists 19.3.6, 19.4.3 and 19.5.1 as the fixes for several other vulnerabilities. An older-branch backport doesn't settle every issue in the advisory.
Operators moving between release lines should follow GitLab's upgrade-path instructions. Required intermediate stops allow background migrations to complete before the next upgrade. The documentation also says to use the latest patch at each stop. For an old installation, the destination in the table is only part of the work: check which intermediate versions the supported route requires before attempting the move.
Check whether the crash logs are collected
GitLab's native-worker crash detection looks for a Ruby [BUG] report alongside an org-ruby or Onigmo stack frame. Onigmo is the regular-expression engine involved. For an Omnibus installation, the relevant Puma worker error log is /var/log/gitlab/puma/puma_stderr.log. GitLab warns that native crash reports often aren't shipped by default, so a search of centrally collected application logs may miss the relevant file entirely.
The rule's ingestion notes identify another failure case. Ruby crash reports span multiple lines. The single-event rule expects the crash marker and stack frames in one event. If a log shipper splits them, operators need correlation by host or pod over a short window. GitLab also lists benign parser bugs as possible false positives. A matching crash needs investigation; an absent match cannot clear the instance. We reviewed the published guidance and did not reproduce the exploit or test the rule against a running server.
Watch the advisory for revisions as operators patch and investigate. GitLab says detailed security issues become public 90 days after the release that fixes them. Until then, its detection guidance gives specific signals to examine, with an explicit limit on what their absence can prove.