GitLab CVE-2026-110264: CVSS 10.0 RCE and fixed versions

CVE-2026-110264 is a critical flaw in GitLab Community and Enterprise Edition that GitLab rates CVSS 10.0. GitLab says it could have allowed an unauthenticated user to execute arbitrary code on the GitLab server. GitLab released the fix on 21 October 2026. If you run self-managed GitLab, upgrade to 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 or 19.5.1, whichever matches your line.

Who is affected by GitLab CVE-2026-110264?

Anyone who runs their own GitLab server, Community Edition or Enterprise Edition, on a version below the fix for its line. GitLab's notice says that when no deployment type is named for a fix, all types are affected. That covers Linux packages, Docker, Helm and source installs alike.

You are not asked to act if you only use GitLab.com. GitLab says GitLab.com is already running the patched version. GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 or later already include the fixes.

GitLab describes the flaw as one that could have allowed an unauthenticated user to execute code, so no account is needed. GitLab does not say that private-network instances are out of scope.

What is the trap with GitLab version numbers?

Two things catch people.

1. Each line has its own fix. The notice lists a separate fixed release per line. 19.2.8 is vulnerable and 19.2.9 is fixed. 19.3.6 is the fix for 19.3, so moving a 19.2 server to 19.3.1 does not help.
2. Older instances cannot jump. GitLab requires upgrade stops, and says to let background migrations finish before the next stop. For GitLab 19 the stops are 19.2, 19.5, 19.8 and 19.11. Use the Upgrade Path tool from GitLab Support to plan the route from your version to a fixed one. The step-by-step GitLab version check and safe upgrade is on its own page.

A container image or a pinned Helm chart also keeps the old version until you rebuild or redeploy it.

How do I patch self-managed GitLab?

GitLab's notice says to upgrade all self-managed installations immediately. It also says single-node instances will have downtime while migrations finish, and multi-node instances can follow the zero-downtime procedure.

Are you running GitLab yourself?

• Read the version your server reports in the Admin area or through your installation's normal version command.
• Find the fixed version for that line in the table below. If you are below 18.11, plan the required upgrade stops with GitLab's tool.
• Take a backup and schedule the downtime window.
• Upgrade, let migrations complete, and read the version again afterwards.
• Rebuild and redeploy any container image or Helm release that pins the old version.
• Review the two GitLab detections (Onigmo native worker crash, Org mode render error burst) against your logs. A detection hit is a lead, not proof of compromise.

Source: GitLab notice, at our check on 24 October 2026. The same release also fixes eleven other issues, the highest rated CVSS 8.2. The notice lists them.

Does someone else host GitLab for you?

An agency, an MSP or a platform team may run GitLab for you. Ask this and keep the reply:

For [our GitLab instance URL], which GitLab version is the server running now, and when was it upgraded? Is it at or above the fixed release for its line for CVE-2026-110264 (18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 or 19.5.1)? If not, when will it be?

If nobody can answer, that is the "unknown" state below.

Was GitLab CVE-2026-110264 exploited?

GitLab's notice released two threat detections for self-managed customers and does not say whether exploitation has been observed. At our check on 24 October 2026 we found no primary source that confirms it.

GitLab says the issues detailing each vulnerability are made public 90 days after the release.

GitLab's notice names the two detections as Onigmo native worker crash and Org mode render error burst. The notice gives no containment or credential-rotation steps, so we give none here. Ask GitLab support or your security team what to do if either detection fires.

What is the bug, without the exploit?

GitLab describes an integer overflow while compiling a specially crafted regular expression. Under certain conditions it could let an unauthenticated user execute arbitrary code on the GitLab server. We do not reproduce exploit details here, and you do not need them to fix your instance.

For the wider picture of what else broke this month, see the October 2026 tracker, the known-exploited edge appliance list, and the other incident write-ups. Another pre-auth bug in self-hosted tooling is covered in the Atlassian file-read patch guide. If you are unsure who owns patching for your site, start with a plain-English guide to who patches what.