GitLab Critical Patch: Remote Code Execution Without Login

• You run your own GitLab server

  Linux package, Docker, Helm chart or source install, CE or EE

  Act now

  Upgrade today. Every version from 7.0 is affected, and GitLab offers no workaround. Find your fixed version

• You patched GitLab on 12 October

  Running 19.4.2, 19.3.5 or 19.2.8

  Act now

  You are still affected. That release fixed an earlier regex flaw. This one needs the next patch up: 19.4.3, 19.3.6 or 19.2.9. How the two differ

• You run GitLab 18.10 or older

  Any version before the 18.11 line

  Act now

  No fixed release exists for your version. Upgrade to 18.11.13 or later, which may take several steps. Plan the upgrade path

• You use GitLab.com

  GitLab’s hosted service

  Protected

  Nothing to do. GitLab.com already runs the fixed version.

• You use GitLab Dedicated

  Single-tenant hosted by GitLab

  Protected

  Nothing to do. Tenants on 19.3.5-internal0, 19.4.2-internal0 or later already have the fixes.

1. 01

   List every GitLab server you run

   Include Geo secondaries (read-only replicas), staging, disaster recovery and test instances. A forgotten instance is still a way in.
2. 02

   Check each version

   Run the command for your install type, or open /help while signed in. How to check
3. 03

   Install the fixed patch for your line

   Stay on the minor version you run, for example 19.4.x to 19.4.3. A patch upgrade needs no extra upgrade stops. Fixed versions
4. 04

   On 19.2 or older, plan a move to 19.3.6 or later

   The older backports carry only the critical fix. The other 11 fixes, including two rated high, need 19.3.6, 19.4.3 or 19.5.1. Moving across minor versions may need upgrade stops. Plan the upgrade path
5. 05

   Look for exploitation attempts

   Load GitLab’s two detection rules and run them over recent logs. What to look for

GitLab normally patches only the three newest minor versions. It backported the critical fix to 19.2, 19.1, 19.0 and 18.11 because of its severity.

Downtime: only 19.4.3 and 19.3.6 include database migrations. A single-node server stays down until they finish. Multi-node installations can follow the zero-downtime upgrade procedure.

sudo cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

docker exec <container> cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

helm list --all-namespaces | grep -i gitlab

For the Helm chart, read the APP VERSION column, not the chart version. If you set global.gitlabVersion, that value wins.

curl --header "PRIVATE-TOKEN: <your-token>" \
  "https://gitlab.example.com/api/v4/version"

GitLab uses Ruby’s built-in regular expression engine, Onigmo. When that engine compiles a specially crafted regular expression, a number overflows. GitLab says an attacker without an account could use this, under certain conditions, to run code on the server.

The flaw is in the engine, not in one GitLab feature. That is why it reaches back to GitLab 7.0, released in 2014, according to The Hacker News.

How it differs from the 12 October fix

• CVE-2026-97229, fixed on 12 October, was a similar overflow reached through CI/CD configuration. It affected only 19.2 to 19.4.
• CVE-2026-110264 is a separate flaw with a wider reach. A server upgraded to 19.4.2, 19.3.5 or 19.2.8 is still exposed.
• Both were reported by the same researcher, joaxcar, through GitLab’s HackerOne bug bounty program.

What is still unknown

• The attack path. GitLab has not said which feature an attacker uses to reach the engine. The name of one detection rule points at rendering Org mode files (a plain-text document format GitLab displays like Markdown), but GitLab has not confirmed it.
• A workaround. GitLab published none. Without a known attack path, no setting can be trusted to block it.
• Exploitation. GitLab’s advisory does not report attacks, and the flaw was not in the CISA KEV catalog at publication. Rapid7 reproduced code execution for the 12 October flaw within a day of its release.

GitLab makes the issue reports public 90 days after the fix, so full details are expected in January 2027.

• Account takeover through SAML and LDAP auto-linking

  CVE-2026-15723 · CE/EE, from 10.1

  High

  CVSS 8.2

  A logged-in user could take over an existing LDAP-backed account without the owner doing anything.

  Who should care: Instances with both OmniAuth SAML and LDAP auto-linking turned on.

• Cache poisoning of OAuth and OpenID Connect discovery

  CVE-2026-112212 · CE/EE, from 18.3

  High

  CVSS 7.5

  An attacker without an account could poison a cached discovery document so some sign-in flows point to a server they control.

  Who should care: Instances behind a shared cache that use GitLab as an OAuth or OIDC provider.

• read_api tokens could create work items

  CVE-2026-12664 · CE/EE, from 18.2

  Medium

  CVSS 6.8

  A read-only API token could fetch a project’s incoming email address and use it to create work items.

  Who should care: Anyone who hands out read_api tokens to integrations or people.

• SAML and LDAP membership lock not fully enforced

  CVE-2026-16255 · EE, from 12.0

  Medium

  CVSS 5.9

  Membership requests made before the lock was switched on could still be granted, adding members outside your identity provider.

  Who should care: Instances that rely on the instance-wide membership lock.

• Internal credentials in response headers

  CVE-2026-105777 · CE/EE, from 17.6.5

  Medium

  CVSS 4.3

  Internal server credentials could leak through response headers that were not filtered.

  Who should care: All self-managed instances.

• Group milestones API leaks private projects

  CVE-2026-13319 · CE/EE, from 15.10

  Medium

  CVSS 4.3

  Any logged-in user could read milestone titles, descriptions and full project paths from private projects they are not a member of.

  Who should care: Instances with private projects and many user accounts.

• Paid AI features without a subscription

  CVE-2026-112378 · EE, from 17.8

  Medium

  CVSS 4.3

  A logged-in user could reach paid GitLab Duo features without a valid subscription.

  Who should care: Mostly a licensing issue. Low risk to your data.

• Confidential issue titles leaked through caching

  CVE-2026-105711 · CE/EE, from 15.0

  Low

  CVSS 3.5

  When a public merge request referenced a confidential issue in a private project, other users could read that issue’s title.

  Who should care: Instances that mix public and private projects.

• Merge request approval policy bypass

  CVE-2026-14288 · EE, from 17.4

  Low

  CVSS 3.1

  A logged-in user could get past a required approval policy on a protected branch while approval rules were syncing.

  Who should care: Teams that use approval policies as an audit control.

• Read-only users could delete vulnerability records

  CVE-2026-112326 · EE, from 17.8

  Low

  CVSS 3.1

  An error during security scanning could delete existing vulnerability records, triggered by a user with read-only access.

  Who should care: Teams that keep vulnerability findings in GitLab as evidence.

• Group Owners could override the Duo admin lock

  CVE-2026-103515 · EE, from 19.2

  Low

  CVSS 2.7

  A group Owner could re-enable Amazon Q, sending data to a third-party AI service, after an administrator had locked Duo off.

  Who should care: Instances that lock AI features for data residency reasons.

“From” is the first affected version. EE means only Enterprise Edition is affected. For CVE-2026-105777, GitLab’s description says no login is needed, but its CVSS score assumes a logged-in user.

• Onigmo native worker crash: a GitLab worker crashing inside the regular expression engine.
• Org mode render error burst: a sudden run of errors while rendering Org mode files.

Get both from the TLDR repository. They are written in Sigma, a shared rule format that converts to the query language of most log monitoring tools (SIEMs). GitLab’s detection guide explains how to deploy them and what to do when one fires.

A crash is a reason to investigate, not proof of compromise. If you find signs of a successful attack, treat the server as compromised. Code would run as the account GitLab itself runs as, so rotate CI/CD variables, runner tokens, deploy keys and access tokens held on it.

The descriptions above are our reading of the rule names. Check each rule’s own page for the log sources and fields it needs.

1. 2026-09-23

   2026-09-23

   GitLab fixes CVE-2026-93577 and CVE-2026-89078, two regex engine code execution flaws that need a logged-in account.

   The Hacker News

2. 2026-10-12

   2026-10-12

   GitLab fixes CVE-2026-97229, a CVSS 10.0 regex flaw reached through CI/CD configuration, in 19.4.2, 19.3.5 and 19.2.8.

   GitLab patch release post

3. 2026-10-13

   2026-10-13

   Rapid7 reproduces code execution for CVE-2026-97229 on GitLab 19.4.1.

   Rapid7

4. 2026-10-21

   2026-10-21

   GitLab releases seven versions fixing CVE-2026-110264 and 11 other flaws, and publishes two detection rules.

   GitLab patch release post

Evidence to keep: when you assessed it, the list of instances, versions before and after, upgrade and downtime times, the detection results, and any secrets you rotated.

For how these controls work day to day, see our guides to ISO 27001 vulnerability management, SOC 2 vulnerability management, ISO 27001 change management and SOC 2 secrets management.

• GitLab critical patch release 19.5.1, 21 October 2026All 12 CVEs, affected versions, CVSS scores and upgrade notes.
• GitLab critical patch release 19.4.2, 12 October 2026The earlier regex flaw, CVE-2026-97229.
• GitLab TLDR detection rulesGitLab’s open-source Sigma rules, including the two for this flaw.
• GitLab security incident detectionHow to deploy the TLDR rules and what to do when one fires.
• The Hacker News, 21 October 2026Why the flaw reaches back to 7.0, and the earlier regex fixes.
• Rapid7 technical analysis of CVE-2026-97229How the earlier flaw turns a regular expression into code execution.
• GitLab upgrade documentationUpgrade steps for each installation method.