In this article
  1. What happened
  2. Why it matters
  3. What to do now
  4. Updates

TL;DR: GitLab released a critical patch on October 21, 2026, for a flaw it rates CVSS 10.0, the maximum. CVE-2026-110264 could let an unauthenticated user “execute arbitrary code on the GitLab server” by getting it to compile a specially crafted regular expression. It affects every GitLab Community and Enterprise Edition version from 7.0 up to the fixed releases: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. GitLab.com is already patched. If your team runs its own GitLab server, GitLab says to upgrade “immediately.”

What happened

GitLab’s patch release covers 12 security fixes. The one that matters most is CVE-2026-110264, which GitLab describes as an integer overflow in its regular expression compiler. GitLab says that “under certain conditions” it “could have allowed an unauthenticated user to execute arbitrary code on the GitLab server.” In other words, an attacker wouldn’t need an account on your instance.

According to GitLab’s release post:

  • Affected versions: GitLab CE/EE 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.
  • Backports: GitLab says it went beyond its usual supported versions and backported the fix to 18.11.13, 19.0.10, 19.1.9 and 19.2.9.
  • Score: CVSS 10.0, the maximum. GitLab’s CVSS vector rates it as reachable over the network, with low attack complexity, no privileges and no user interaction needed.
  • Who is already covered: GitLab.com runs the patched version. GitLab Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later already have the fixes.
  • Detection: GitLab has published two threat detections for self-managed instances, named “Onigmo native worker crash” and “Org mode render error burst.” (Onigmo is the regular expression engine used by Ruby, which GitLab is built on; each fixed release’s change list includes a Ruby regexp patch.)
  • Other fixes: two High-severity flaws, CVE-2026-15723 (an account takeover when OmniAuth SAML and LDAP auto-linking are both enabled, CVSS 8.2) and CVE-2026-112212 (cache poisoning of OAuth/OIDC discovery documents, CVSS 7.5), plus five Medium and four Low issues.

GitLab’s post doesn’t say whether CVE-2026-110264 has been exploited. It says details of each fixed vulnerability go public on its issue tracker 90 days after the release.

Why it matters

Small teams often run a self-managed GitLab instance on a single server or VM to host their code, CI/CD pipelines and deployment secrets. A flaw that needs no login, on a server that is often reachable from the internet, puts all of that at risk. The patch has been public since October 21, and in the PHP2Shell case this week AWS warned that AI-assisted analysis can turn a patch into a working exploit within hours. Treat this as an emergency patch, not something for your next maintenance window.

What to do now

  1. Check your version. Sign in as an administrator and open /help on your instance (or the Admin area) to see the version. If it’s below the fixed release for your branch, you’re affected.
  2. Upgrade to the fixed release for your branch: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13. If you’re on an older branch than 18.11, plan an upgrade path to a supported release; GitLab lists no fix for branches before 18.11.
  3. Plan for downtime on single-node servers. GitLab says this patch includes database migrations: single-node instances will be down while migrations run, and multi-node instances can upgrade without downtime if they follow GitLab’s zero-downtime procedure. 19.4.3 and 19.3.6 include regular migrations, and 19.4.3 also has post-deploy migrations.
  4. Take a backup first, so you can roll back if the upgrade fails.
  5. If you can’t upgrade tonight, limit exposure. Restrict access to the instance to your VPN or office IPs until you can patch. This is our own suggestion as a stopgap; GitLab’s only fix is the upgrade.
  6. Look for signs of attack. GitLab has published two detection rules for self-managed instances, Onigmo native worker crash and Org mode render error burst. Run them against your GitLab logs, and if either matches or anything else looks wrong, rotate CI/CD variables, deploy keys and access tokens stored on the instance.
  7. If you use GitLab.com, there’s nothing to patch: GitLab says GitLab.com already runs the patched version.

If you’re patching servers tonight anyway, also check our story on the critical PHP security release, which attackers are already exploiting.

Updates

  • Oct 22, 2026, 10:20 p.m. Manila: First published. We’ll add a dated note here if GitLab reports exploitation, revises its advisory or ships further fixes.

Sources & method

Sources

Method. Checked October 22, 2026, at 10:20 p.m. Manila time (14:20 UTC). The affected and fixed versions, CVSS scores, descriptions, detections, GitLab.com and Dedicated status and the migration notes come from GitLab’s patch release post. The note on AI-assisted exploit development comes from AWS’s post. The steps under “What to do now” are our own judgment, built on GitLab’s guidance. No affiliate links on this page. How we work.

Spotted an error? See our corrections policy and tell us.