Who this is for: administrators who run GitLab on their own servers or cloud (self-managed), and developers who build applications in Ruby. This page is based on GitLab's patch release notice, Ruby's official announcement, the US National Vulnerability Database (NVD) and CISA's public data. It does not cover how attacks work.
続報待ち：この記事は公式発表に合わせて更新します
as of 08:00 JST, October 25, 2026まだ分かっていないこと
- The exact conditions under which the flaw can be triggered (GitLab says only 'under certain conditions')
- Any change in exploitation status (none reported at disclosure)
- NVD's own assessment (undergoing analysis)
GitLab published the patch release on October 21, and the Ruby team released fixed versions on October 23. No exploitation has been reported, and the flaw is not in CISA's KEV catalog. GitLab says details will be made public 90 days after the release. This page will be updated if the situation changes.
What to do today (self-managed GitLab)
Check the version
On a Linux package (Omnibus) installation, run sudo gitlab-rake gitlab:env:info on a node that runs GitLab Rails; the version appears in the "GitLab information" section. You can also see it in the Admin area when signed in as an administrator. On multi-node setups, check every node.
Move to the fixed release in the same line
If you are on 19.4.x, go to 19.4.3; on 19.3.x, go to 19.3.6, and so on. In this site's view, a patch upgrade within the same minor line normally does not involve upgrade stops (check with GitLab's tool to be sure). GitLab says single-node instances should expect downtime, because GitLab does not start until migrations finish. Multi-node instances can use the zero-downtime upgrade procedure.
From older versions, check the upgrade stops first
GitLab defines required upgrade stops that must not be skipped. As of October 2026 the list includes 18.2, 18.5, 18.8 and 18.11 for GitLab 18, and 19.2, 19.5, 19.8 and 19.11 for GitLab 19 (of the GitLab 19 stops, 19.2 and 19.5 are released). Enter your current and target versions in GitLab's Upgrade Path tool to get the versions you must pass through. GitLab says you must upgrade to these versions before later ones, and wait for background migrations to finish at each stop.
If you cannot upgrade right away, restrict who can reach it
GitLab's notice gives no workaround other than upgrading. Until you upgrade, this site recommends keeping GitLab unreachable from outside your network with a firewall or VPN and turning off new sign-ups. Neither closes the hole, so keep the upgrade moving.
Look for traces
GitLab has published two threat detections for self-managed customers (the "Detecting CVE-2026-110264 Exploitation Attempts" section of the notice). If you have log monitoring, load them. Also look for unfamiliar processes, files, administrator accounts and outbound connections. See how to check whether your server was compromised.
Am I affected? Quick table
| What you run | CVE-2026-110264 (Critical) | High-severity flaws and others in the same release | Target |
|---|---|---|---|
| 19.5.x before 19.5.1 | Affected | Affected | 19.5.1 |
| 19.4.x before 19.4.3 | Affected | Affected | 19.4.3 |
| 19.3.x before 19.3.6 | Affected | Affected | 19.3.6 |
| 19.0.x to 19.2.x | Affected (fixed in 19.0.10, 19.1.9, 19.2.9) | Fixed only in 19.3.6 and later | 19.3.6 or later |
| 18.11.x before 18.11.13 | Affected (fixed in 18.11.13) | Fixed only in 19.3.6 and later | 19.3.6 or later |
| 18.10 and older (7.0 onward) | Affected | Depends on the flaw | Newer version via the upgrade stops |
| GitLab.com | Patched | Patched | No action |
| GitLab Dedicated | Patched from 19.3.5-internal0, 19.4.2-internal0 | Same | No action, per GitLab |
The affected range differs for each of the other flaws (for example, CVE-2026-15723 starts at 10.1 and CVE-2026-112212 at 18.3). Check the table in GitLab's notice for the exact ranges.
Current version
Before the fix, the critical flaw remains
18.11.13 to 19.2.9
Critical fixed, High flaws remain
19.3.6 / 19.4.3 / 19.5.1
Every fix in this release
What was disclosed (from GitLab's notice)
- CVE
- CVE-2026-110264 (CWE-190: integer overflow)
- Severity
- Critical, CVSS v3.1 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, GitLab's rating)
- Issue
- Under certain conditions, an integer overflow when compiling a specially crafted regular expression could allow an unauthenticated user to execute arbitrary code on the GitLab server
- Affected
- GitLab CE/EE from 7.0, before 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1
- Already fixed
- GitLab.com; GitLab Dedicated from 19.3.5-internal0 and 19.4.2-internal0
- Reported by
- An external researcher, through GitLab's bug bounty program on HackerOne
- Exploitation
- Not stated in the notice; not in CISA's KEV catalog as of October 25
The same release fixes 11 other vulnerabilities, two of them High. CVE-2026-15723 (CVSS 8.2) could let an authenticated user take over an existing LDAP-backed account when OmniAuth SAML and LDAP auto-linking are both enabled. CVE-2026-112212 (CVSS 7.5) could let the cached OAuth/OIDC discovery document be poisoned so that certain flows are sent to an external server. The rest are five Medium and four Low.
CISA's SSVC assessment dated October 21 lists exploitation as "none", automatable as "yes" and technical impact as "total". Finishing the upgrade while no exploitation has been reported is the cheapest way through this (this site's view).
The root cause is in Ruby's regex engine: for Ruby developers
On October 23, the Ruby team released Ruby 4.0.9, 3.4.12 and 3.3.13, which fix bugs in Ruby's regular expression engine (Onigmo). They fix three bugs related to four CVEs assigned by GitLab (CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264). The three besides CVE-2026-110264 were fixed in GitLab 19.4.1 and 19.4.2.
Regexp.timeout does not help
According to Ruby's announcement, the bugs are reached only when an application compiles a regexp from a string an attacker controls (Regexp.new, Regexp.union, Regexp.compile, or interpolation such as /#{input}/). Applications that use only developer-written regexps are not affected. Regexp.timeout does not protect against these bugs, and limiting pattern length is not reliable either.
Ruby 3.3 is in security-only maintenance, but 3.3.13 includes these fixes as an exception because GitLab assigned CVEs to issues that rely on them. Ruby 3.2 reached end of life on April 1, 2026, and has no fixed release.
GitLab's Linux packages and cloud native images carry GitLab's own regexp patches, so GitLab administrators update GitLab itself, not the server's Ruby. If you installed GitLab from source, this site recommends updating that Ruby to a fixed release as well.
Risky patterns
- Passing search-box or filter input straight to Regexp.new
- Running patterns that users register as server-side regexps
- Assuming Regexp.timeout or a length limit makes it safe
- Staying on Ruby 3.2 or older after end of life
Safer patterns
- For plain text search, use Regexp.escape so the input is matched literally
- Ask whether letting users write regexps is really needed
- If it is, run it with a different regex engine or in an isolated process (this site's view)
- Upgrade Ruby to 4.0.9, 3.4.12 or 3.3.13 or later
Whether a gem or framework you depend on builds regexps from user input cannot be seen from your own code alone, so upgrading Ruby is the most reliable fix. For watching dependencies, see how to monitor dependency CVEs with osv-scanner.
What self-hosted Git servers tend to forget
Running GitLab yourself removes some accidents, such as a repository made public by mistake, but the job of patching moves to you. With a flaw that reaches back to 7.0, the servers that stopped updating long ago have the most upgrade stops to pass and the heaviest work.
This site's view: keep up to at least one stop behind the latest required upgrade stop in normal times. Then an emergency upgrade is one or two steps, not a long chain. For the trade-offs of self-hosting, see self-hosted Git vs GitHub: which is safer.
What is still unknown
| Item | Status |
|---|---|
| The exact conditions for the flaw | Not stated ("under certain conditions"; details to be published 90 days after the release) |
| Exploitation | Not stated (not in CISA's KEV as of October 25) |
| Public exploit code | Not stated |
| NVD assessment | Undergoing analysis (GitLab's rating is 10.0) |
| CVEs for the Ruby bugs themselves | Not yet requested by the Ruby team (may be revisited) |
Sources
- GitLab, "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" (October 21, 2026) — docs.gitlab.com
- Ruby, "Regexp compilation fixes related to GitLab's CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264" (October 23, 2026) — ruby-lang.org
- Ruby, "Ruby Maintenance Branches" — ruby-lang.org
- GitLab, "Upgrade paths" — docs.gitlab.com
- GitLab, "Maintenance Rake tasks" (gitlab:env:info) — docs.gitlab.com
- NIST NVD, "CVE-2026-110264" — nvd.nist.gov
- CISA, "Known Exploited Vulnerabilities Catalog" — cisa.gov
Change log
2026-10-25: First version, based on GitLab's patch release notice, Ruby's official announcement, NVD and CISA's KEV catalog (October 23, 2026 version).
Read next
- Self-hosting trade-offs: Self-hosted Git vs GitHub: which is safer
- Prioritizing: How to decide which CVEs to fix first (CVSS, EPSS, KEV)
- Checking for compromise: How to check whether your server was compromised
- Another runtime fix the same week: PHP vulnerabilities CVE-2026-109618 and CVE-2026-109619
- Terms: What is RCE (remote code execution) / What is CVSS