GitLab CVE-2026-110264: which version to upgrade to and how

As of October 24, 2026, 06:24 JST (October 23, 21:24 UTC). Every fact that can change carries the time it was checked, in JST (UTC+9). This page covers GitLab's critical patch release of October 21, 2026, and CVE-2026-110264 in it.

GitLab 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13, released October 21, 2026, fix CVE-2026-110264, a CVSS 10.0 bug that lets an unauthenticated attacker run code on a self-managed GitLab server. GitLab.com is already patched. GitLab 18.10 and older get no fix: upgrade to 18.11.13 or later.

Install the fixed version of the minor release you run. If your line has no fix, go through the required upgrade stops to 18.11.13 or later. Every self-managed install type needs this: the Linux package (Omnibus), Docker, the Helm chart, the Operator, and self-compiled installs. On a self-compiled install, Ruby needs an update too: GitLab fixed its own packages "by patching the Ruby it ships", in the Ruby team's words. As checked at 06:24 JST on October 24, CISA's Known Exploited Vulnerabilities catalog doesn't list CVE-2026-110264, and GitLab's post doesn't say whether it has been exploited.

Below: the fixed version and Helm chart for each line, who is affected, the 12 CVEs of the release with their scores, the upgrade path from each starting version back to 13.12 and the commands for each install type, GitLab's two detections, and what is known about exploitation.

Which GitLab versions are fixed

The fixed versions are from GitLab's patch release post of October 21, 2026, which says GitLab has "backported this fix to GitLab CE/EE versions 18.11.13, 19.0.10, 19.1.9, and 19.2.9" in addition to its standard patch releases (checked 05:36 JST on October 24). The support column is GitLab's maintenance policy, which lists 19.5, 19.4, and 19.3 as maintained (05:40 JST). The chart versions are from GitLab's chart version mappings (05:40 JST): two of them don't follow the GitLab number, so 19.3.6 is chart 10.3.7, not 10.3.6, and 18.11.13 is chart 9.11.14. The image times are the gitlab/gitlab-ee and gitlab/gitlab-ce tags on Docker Hub (05:41 JST). The apt repository for Ubuntu 24.04 lists all seven gitlab-ee packages (05:42 JST).

None of the fixed versions is exposed to three earlier bugs in the same regular expression engine: GitLab lists them as affecting 19.2 and later only, and 19.2.9 and later already carry their fixes: CVE-2026-89078 and CVE-2026-93577 (CVSS 9.9 each, fixed in 19.4.1, 19.3.3, and 19.2.7 on September 23) and CVE-2026-97229 (CVSS 10.0, fixed in 19.4.2, 19.3.5, and 19.2.8 on October 12).

Am I affected?

GitLab's post lists the affected versions as "all versions from 7.0 before 18.11.13, 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1", for both Community Edition (CE) and Enterprise Edition (EE). It adds: "When no specific deployment type (omnibus, source code, helm chart, etc.) of a product is mentioned, it means all types are affected."

To see your version, open Help > Help from the bottom of the left sidebar while signed in, or call GET /api/v4/version with an access token. On a Linux package install, GitLab's upgrade path tool suggests grep gitlab /opt/gitlab/version-manifest.txt. On the Helm chart, helm list shows the chart version, which you map back with the table above.

What an attacker needs is not in the release post. GitLab's detection guide for this CVE says: "The attack needs no authentication — only one public project that can hold the .org payload." The bug sits in how GitLab renders Org-mode (.org) files: the org-ruby gem passes a keyword from the file into a regular expression, and a keyword with more than 32,767 repeats overflows an ID inside Onigmo, Ruby's regular expression engine. Until you can upgrade, the same guide says to "reduce public visibility where possible — the unauthenticated path needs a public .org file that GitLab renders". That narrows only that path. The guide also describes a second one, the editor preview: GitLab's preview "chooses the renderer from File.basename(file_path), so a .org file_path forces the Org renderer regardless of the real file", and its sample request comes from a signed-in user. Making projects private doesn't close that route, and where sign-up is open, anyone can become a signed-in user. The release post names no workaround.

The 12 CVEs in this release

The titles and scores below are GitLab's, word for word (checked 05:36 JST). Every score is CVSS 3.1.

Only CVE-2026-110264 was backported to 19.2, 19.1, 19.0, and 18.11. The other 11 are listed as fixed in 19.3.6, 19.4.3, and 19.5.1, so 19.2.9, 19.1.9, 19.0.10, and 18.11.13 still carry each of them whose range reaches back that far. CVE-2026-15723, from 10.1, reaches all four.

CVE-2026-110264's vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: over the network, low complexity, no privileges, no user interaction. GitLab is the CVE Numbering Authority. Its record at CVE.org was published on October 22 at 00:33 UTC (09:33 JST) with the weakness CWE-190, Integer Overflow or Wraparound. The NVD lists the record as "Undergoing Analysis" with GitLab's 10.0 and no score of its own (checked 06:24 JST on October 24). The reporter, per GitLab, is joaxcar, through its HackerOne bug bounty program.

Upgrade path from your version

GitLab requires upgrade stops: versions you must install, and whose background migrations must finish, before you go further. From 17.5 on, the stops are x.2, x.5, x.8, and x.11, so 18.2, 18.5, 18.8, 18.11, 19.2, and 19.5 (GitLab's upgrade path docs, checked 05:37 JST). The rows below are what GitLab's own upgrade path tool returned for each starting version (checked 05:38–05:53 JST and, for 13.12 to 17.2, 06:21–06:28 JST on October 24). The tool lists the latest patch of each stop, and if you run an older patch of a stop, such as 18.8.5 or 19.2.8, it installs that stop's latest patch first.

Rows give ranges of minor releases; where a row starts at a stop, such as 18.8 or 18.5, the tool first installs that stop's latest patch if you run an older one, and marks it as a step that "may not be needed". Two more notes on the table. GitLab's docs call 17.1.8 "Required only for instances with large ci_pipeline_messages tables", but the tool includes it. And for every path from 18.8 or older, the tool warns that "Upgrading to GitLab 18.9 might fail with a PG::CheckViolation error" in a post-deployment migration; GitLab's 18 upgrade notes describe the failure and link workarounds. Run the tool yourself for your exact version, edition, and distribution before you start: it also lists the background migrations and deprecations on your path.

Stop at 18.11.13, or go on to 19.5.1?

From 18.8.11, 18.9, 18.10, or 18.11, a fixed version is one install away. Going on to 19.x means two more hops and the changes of GitLab 19.0, among them these, from GitLab's 19 upgrade notes, which list more (checked 05:41 JST):

On 18.11.13, the instance is fixed for CVE-2026-110264 without any of these. The trade-offs: 18.11.13 fixes CVE-2026-110264 only, so the two High bugs of this release, CVE-2026-15723 (8.2, reaching back to 10.1) and CVE-2026-112212 (7.5, from 18.3), stay open there, with the Medium and Low ones whose ranges reach 18.11. The same goes for 19.0.10 and 19.1.9. These backport versions also lack the fixes of GitLab's September 23 and October 12 patch releases, among them High bugs such as CVE-2026-84739 (8.7, from 13.11), CVE-2026-16301 (8.5, from 18.7), and CVE-2026-14814 (8.2, all versions before 19.2.8), whose affected ranges reach 18.11, 19.0, and 19.1 (both posts checked 06:22 JST). GitLab said as much when it backported two earlier fixes to 18.11.12 and 19.0.9 on September 23: "Upgrading to the latest supported version remains the recommended path, because 18.11 and 19.0 do not receive the other fixes included in 19.1.8, 19.2.6, and 19.3.2." And 18.11 isn't a maintained line: GitLab's policy promises security fixes only for the current release and the two before it. When 19.6 ships, scheduled for the third Thursday of November (November 19, 2026), the maintained lines move to 19.6, 19.5, and 19.4. Also, upgrading to 18.11 itself "triggers an automatic upgrade to PostgreSQL 17.7 for single-node Linux package installations", per GitLab's 18 upgrade notes.

Commands for each install type

Each hop is one install of one exact version. The table uses 18.11.13 as the example; repeat it with each version on your path.

The chart versions for the stops on the way (GitLab's version mappings, 05:40 JST): 18.2.8 is chart 9.2.8, 18.5.7 is 9.5.7, 18.8.11 is 9.8.12, 18.11.13 is 9.11.14, 19.2.9 is 10.2.9, and 19.5.1 is 10.5.1. Every fixed chart was in the Helm repository's index by October 21 at 17:59 UTC (checked 05:41 JST on October 24).

For the Operator, the release that names a fix matters. Operator 3.5.1 (October 21, 16:21 UTC) lists charts 10.5.1, 10.4.3, and 10.3.7. Operator 3.1.5 (October 22, 06:10 UTC) lists charts 10.1.9 and 10.0.10, and a chart 9.11.15 with no GitLab version beside it; the Helm repository has no chart 9.11.15, and maps 18.11.13 to 9.11.14. No Operator release lists chart 10.2.9 for 19.2.9 (all checked 05:45 JST on October 24).

GitLab's post adds that this patch has database migrations: regular migrations in 19.4.3 and 19.3.6, and post-deploy migrations in 19.4.3. "Single-node instances: This patch will cause downtime during the upgrade as migrations must complete before GitLab can start."

Self-compiled installs need a Ruby update

The bug is in Onigmo, the regular expression engine inside Ruby. On October 23 at 03:11 UTC (12:11 JST), the Ruby team released Ruby 4.0.9, 3.4.12, and 3.3.13 with the fix, and said GitLab "addressed these issues in its own releases by patching the Ruby it ships". The bug fix lists of 19.2.9 to 19.5.1 in GitLab's post include "Add Ruby regexp repeat ID overflow patch for 3.3, 3.4 and 4.0". The Linux package, the Docker images, and the Helm chart's images carry their own Ruby. A self-compiled install runs the Ruby you installed.

GitLab's self-compiled install guide still lists Ruby 3.2.x as the minimum (checked 05:44 JST). Ruby's advisory adds two warnings for any Ruby app that builds a regular expression from input: "Regexp.timeout does not protect against these bugs", and limiting pattern length "does not reliably protect against them either". GitLab's release post doesn't say whether a self-compiled GitLab on an unpatched Ruby is fixed by the GitLab update alone. GitLab itself runs Ruby 3.3: its .ruby-version file is 3.3.10 at v18.11.13-ee and 3.3.11 at v19.1.9-ee and v19.5.1-ee (checked 06:22 JST). So run ruby -v, and install 3.3.13, or 3.4.12 if you already run 3.4, as the "Update Ruby" step of GitLab's self-compiled upgrade, which comes before its "Install libraries and run migrations" step, where the gems are installed again. A move from 3.2 to 3.3 changes the series, and gems built for the old Ruby have to be built again before GitLab starts.

Look for attempts with GitLab's two detections

GitLab published two detection rules for self-managed instances with the release, in its gitlab-security-oss/tldr repository; their Sigma rules are dated October 20, 2026 (checked 05:42 JST on October 24).

On the Helm chart, both logs come from the Webservice pods (gitlab-webservice-*, container webservice); on a self-compiled install they are under /home/git/gitlab/log/. Without a SIEM, GitLab's guide gives these searches. Org render timeouts, counted per client:

EXC=/var/log/gitlab/gitlab-rails/exceptions_json.log
grep '"exception.class":"Timeout::Error"' "$EXC"* \
  | grep '"extra.class_name":"OtherMarkup"' | grep -E '"extra.file_name":"[^"]*\.org"' \
  | grep -o '"meta.client_id":"[^"]*"' | sort | uniq -c | sort -rn

Editor previews that force the Org renderer onto a file that isn't .org ("any hit is notable", per the guide):

PROD=/var/log/gitlab/gitlab-rails/production_json.log
grep 'Projects::BlobController#preview' "$PROD"* | grep '"file_path"' | grep -E '\.org"'

Native crashes through org-ruby or Onigmo:

PUMA=/var/log/gitlab/puma/puma_stderr.log
grep -B1 -A20 '\[BUG\]' "$PUMA"* \
  | grep -E 'org-ruby|headline\.rb|regexp_helper\.rb|regexp_matcher\.rb|match_at|onig_search_gpos|onig_compile|compile_tree|compile_length_tree|rb_str_sub_bang'

The Org mode guide also gives a ripgrep search to run in a checkout of each suspect repository: it lists .org files with a task-keyword line (the #+ lines that declare Org's task states, #+SEQ_TODO:, #+TYP_TODO:, and the plain form without a prefix, which is the one GitLab's guide names for the payload) longer than 500 characters.

If you find signs of code execution, GitLab's guide says to "treat the instance as compromised: rotate the secrets in gitlab-secrets.json, all CI/CD variables, all runner tokens, and all access tokens", and to keep the full crash report and the Rails and Workhorse logs before any restart.

Is CVE-2026-110264 being exploited?

No source this page checked reports attacks in the wild (first read 05:36–05:45 JST, read again at 06:24 JST on October 24):

Earlier GitLab bugs did get used: one remote code execution bug, CVE-2021-22205, is in CISA's catalog with "Known" use in ransomware campaigns.

Upgrade GitLab to a fixed version

1. Find your version and install type

Open Help > Help while signed in, or call GET /api/v4/version with an access token. Note whether you run CE or EE, and whether GitLab came from the Linux package, Docker, the Helm chart, the Operator, or source.

2. Get your path from GitLab's upgrade path tool

Enter your version in GitLab's upgrade path tool, choose your edition and distribution, and write down each stop. From 18.8.11, 18.9, 18.10, or 18.11, 18.11.13 is one install away; from older versions, every stop in the table above comes first.

3. Back up

At a minimum, back up the database and /etc/gitlab/gitlab-secrets.json (in Docker, the config volume). The Linux package backs up the database before it installs a newer version unless /etc/gitlab/skip-auto-backup exists, and GitLab still says to keep your own full backup.

4. Install one stop at a time

Install each version on your path by its exact number: gitlab-ee=<version>-ee.0 with apt, the <version>-ee.0 image tag on Docker, or the matching chart version with Helm. Don't use latest or a plain package upgrade while stops remain.

5. Let background migrations finish before the next stop

On 18.9 and later, run sudo gitlab-rake gitlab:background_migrations:list until every migration shows finished or finalized; on 18.8 and earlier, the task is sudo gitlab-rake gitlab:background_migrations:status. From 19.5, sudo gitlab-rake gitlab:background_migrations:wait blocks until they finish.

6. On a self-compiled install, update Ruby

Install Ruby 3.3.13, the series GitLab itself runs, or 3.4.12 if you already run 3.4. Do it as the "Update Ruby" step of GitLab's self-compiled upgrade, before the gems are installed again, not as a restart after the last hop. On Ruby 3.2, which gets no fix, move to 3.3.13 the same way. The Linux package, Docker images, and Helm chart images carry their own Ruby and need no separate step.

7. Check the version and the logs

Confirm the new version in Help > Help, then run GitLab's two searches above over the logs from before the upgrade.

Tell your users about the upgrade window

A GitLab that is down for its upgrade can't carry its own notice, so ask an AI chat to write one HTML page with the upgrade window, what changes for your users afterward, and how to reach you. Convika turns that file into a link that stays up while GitLab is down: sign up free, drop the file on the upload screen, check the private preview, and publish. On the free plan the page is public: search engines and Convika's gallery may list it, so leave out the GitLab version, hostnames, IP addresses, and anything internal.

Publish my notice page

Updates to this page

• October 24, 2026, 06:24 JST: first version.

This page changes when CISA adds the CVE to its catalog, when the NVD publishes its own score, when GitLab or anyone with evidence reports exploitation, when an Operator release names chart 9.11.14 or 10.2.9, and at GitLab's next scheduled patch release. GitLab's own pages disagree on its date: the release post says scheduled releases come "on the second and fourth Wednesdays", which would make it October 28, 2026, while the maintenance policy says "the Wednesday the week before and the Wednesday the week after the monthly minor release", which, with 19.6 on November 19, makes it November 11. The same week, Node.js and PHP shipped critical fixes too: Node.js October 2026 security release: what to update and PHP October 2026 security release: what to update.

Frequently asked questions

Which GitLab versions fix CVE-2026-110264?

19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, and 18.11.13, for both CE and EE, released on October 21, 2026. Any later version on those lines also has the fix.

Is GitLab.com affected by CVE-2026-110264?

No action is needed. GitLab's post says "GitLab.com is already running the patched version."

Do GitLab Dedicated customers need to do anything?

No, on 19.3.5-internal0, 19.4.2-internal0, or later. GitLab's post says those tenants "already include these fixes and do not need to take action."

I run GitLab 18.10 or older. Which version should I upgrade to?

18.11.13 at minimum, because no line before 18.11 got the fix, then through 19.2.9 to 19.3.6 or later, because 18.11.13 lacks GitLab's other recent security fixes. From 18.8.11, 18.9, or 18.10 it is one install; from older versions you go through the required stops first, for example 18.5.7 and 18.8.11 from 18.4. GitLab's upgrade path tool gives the exact list for your version.

Can I upgrade straight to 19.5.1?

Only from 19.2.9, 19.3, 19.4, or 19.5.0. From 19.0, 19.1, or an older 19.2 patch you install 19.2.9 first, and from 18.11 you install 18.11.13 and 19.2.9 first, because 18.11 and 19.2 are required upgrade stops.

Is CVE-2026-110264 being exploited?

No source checked at 06:24 JST on October 24 reports it: CISA's Known Exploited Vulnerabilities catalog doesn't list it, CISA's rating in the CVE record says Exploitation "none", and GitLab's post doesn't mention attacks. Public GitHub repositories that name the CVE have existed since October 22, some described as proofs of concept or reproduction labs.

What is the CVSS score of CVE-2026-110264?

10.0, Critical, with the CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, from GitLab as the CVE Numbering Authority. The NVD shows GitLab's score and none of its own yet.

Is there a workaround if I can't upgrade today?

The release post names none. GitLab's detection guide says to "reduce public visibility where possible", because the unauthenticated path needs a public .org file that GitLab renders. That doesn't close the guide's second route, the editor preview with a .org file path, which a signed-in user can reach, so watch the logs with GitLab's detections, the preview search included, and upgrade.

Do I need to update Ruby?

On a self-compiled install, yes: install Ruby 3.3.13, the series GitLab pins, or 3.4.12 if you already run 3.4, both released by the Ruby team on October 23, as the "Update Ruby" step of GitLab's self-compiled upgrade. The Linux package, Docker images, and Helm chart images carry their own Ruby, which GitLab patched in these releases, according to the Ruby team.

Which Helm chart version fixes CVE-2026-110264?

10.5.1 (GitLab 19.5.1), 10.4.3 (19.4.3), 10.3.7 (19.3.6), 10.2.9 (19.2.9), 10.1.9 (19.1.9), 10.0.10 (19.0.10), or 9.11.14 (18.11.13), per GitLab's chart version mappings.

Does the Docker latest tag have the fix?

Yes: gitlab/gitlab-ee:latest and gitlab/gitlab-ce:latest point to 19.5.1 (checked 05:42 JST on October 24). Don't pull it on an instance older than 19.2.9, though: it skips required upgrade stops.

Sources

Times are in JST (UTC+9), on October 24, 2026.

• 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, dated October 21, 2026 (05:36, 06:24)
• GitLab's earlier critical patch releases 19.4.1, 19.3.3, 19.2.7 (September 23), 19.0.9, 18.11.12 (September 23), and 19.4.2, 19.3.5, 19.2.8 (October 12) (05:44, 06:22)
• GitLab upgrade path tool (05:38–05:53, 06:21–06:28) and its data file config/upgrade_path.yml (05:37)
• GitLab: Plan your upgrade path (05:37)
• GitLab: Upgrade Linux package instances, Upgrade Docker instances, Upgrade GitLab Helm chart instances, Upgrade GitLab instances with Operator, and Upgrade self-compiled instances (05:40–05:41)
• GitLab Helm chart versions (05:40) and the chart repository index (05:41)
• GitLab Operator releases (05:45, 06:24)
• GitLab release and maintenance policy (05:40)
• GitLab 19 upgrade notes and GitLab 18 upgrade notes (05:41)
• GitLab: Background migrations (05:40), Find the GitLab version, and Metadata API (05:46)
• GitLab: Install self-compiled, software requirements (05:44), and GitLab's .ruby-version at v19.5.1-ee, v19.1.9-ee, and v18.11.13-ee (06:22)
• Docker Hub: gitlab/gitlab-ee and gitlab/gitlab-ce (05:41–05:42)
• GitLab package repository, gitlab-ee for Ubuntu 24.04 (05:42)
• GitLab security detections: Onigmo native worker crash and Org mode render error burst (05:42)
• CVE.org: CVE-2026-110264 (05:42, 06:24)
• NVD: CVE-2026-110264 (05:42, 06:24)
• CISA Known Exploited Vulnerabilities catalog, version 2026.10.23 (05:42, 06:24)
• Ruby: Regexp compilation fixes related to GitLab's CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264, published October 23, 03:11 UTC (05:43), the Ruby 3.4.12 release (05:43), and Ruby branch status (05:44)
• GitHub repository search for CVE-2026-110264 (05:45, 06:24; counted, not opened)