GitLab: two critical flaws in ten days, from discovery to patch

GitLab: two critical flaws in ten days, from discovery to patch

# security# vulnerability# update# gitlab
GitLab: two critical flaws in ten days, from discovery to patchArmelDev

Two critical flaws (CVSS 10.0) in GitLab's regular expression engine allow code execution on the server. Their timeline, and the steps to update and secure your instances.

On October 21, 2026, GitLab released emergency versions 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. They fix CVE-2026-110264, a critical flaw rated 10.0, the maximum score, which can allow an unauthenticated attacker to execute code on a GitLab server. It is the second flaw of this kind in ten days. Here is what happened, and what to do.

The problem comes from the regular expression engine

Both flaws share the same nature: an integer overflow when compiling a specially crafted regular expression. The component at fault is Onigmo, Ruby's regular expression engine, which GitLab ships in its packages.

  • CVE-2026-97229 (October 12): the malicious expression goes through the CI/CD configuration, in a .gitlab-ci.yml file. It affects versions 19.2 and later.
  • CVE-2026-110264 (October 21): a flaw of the same nature, but affecting every version since GitLab 7.0 , released in 2014. According to the detection rules published by GitLab, it can be triggered by a simple Org-mode ( .org ) file, whose rendering passes an expression to the engine.

In both cases, the code runs as GitLab's git system account, which has access to repositories, CI/CD secrets and the instance configuration.

Every self-managed instance is affected

GitLab.com is already patched and GitLab Dedicated customers have nothing to do. Self-managed instances, Community and Enterprise alike, must be updated.

Branch Fixed version
19.5 19.5.1
19.4 19.4.3
19.3 19.3.6
19.2 19.2.9
19.1 19.1.9
19.0 19.0.10
7.0 to 18.11 18.11.13

Important: the versions released on October 12 (19.4.2, 19.3.5 and 19.2.8) fix the first flaw, but not the second. An instance updated on that date is vulnerable again.

The fixes for 19.2, 19.1, 19.0 and 18.11 are exceptional backports, outside GitLab's usual policy. That alone shows how serious the problem is.

Two other serious flaws in the same update

The October 21 release fixes eleven flaws in total. Two of them, rated high, deserve special attention:

  • CVE-2026-15723 (CVSS 8.2): an authentication flaw that can allow account takeover when SAML authentication and automatic LDAP linking are enabled. Organizations connecting GitLab to their corporate directory are directly concerned.
  • CVE-2026-112212 (CVSS 7.5): a cache poisoning issue in OAuth/OIDC discovery, the mechanism used to sign in through an external identity provider.

These flaws are fixed by the same versions: a single update takes care of everything.

From discovery to patch: a tense month

Date Event
2014 GitLab 7.0 is released. According to the October 21 advisory, every version since then is affected by CVE-2026-110264.
September 23, 2026 GitLab fixes two other critical flaws (CVE-2026-93577 and CVE-2026-89078, CVSS 9.9), exploitable with an authenticated account. According to The Hacker News, researcher joaxcar reported four code execution flaws in GitLab's regular expression engine within a month.
October 12, 2026 CVE-2026-97229 (CVSS 10.0) is fixed in versions 19.4.2, 19.3.5 and 19.2.8.
October 13, 2026 Rapid7 reproduces code execution on the official GitLab CE 19.4.1 image.
October 16, 2026 Researcher Jonah Burgess publishes a proof-of-concept exploit for CVE-2026-97229. Being able to push a branch to a public project on the instance is enough.
October 20, 2026 GitLab publishes two detection rules: "Onigmo native worker crash" and "Org mode render error burst".
October 21, 2026 CVE-2026-110264 (CVSS 10.0) is fixed. It was reported by joaxcar through the HackerOne bug bounty program, and the fix is backported down to the 18.11 branch. The same update fixes ten other flaws, including CVE-2026-15723 (8.2) and CVE-2026-112212 (7.5).
October 21, after the release GitLab reports no exploitation in the wild. CISA has not added the flaw to its catalog of exploited vulnerabilities.

A public exploit already exists for the first flaw, and both share the same root cause. Assume that exposed instances will be targeted.

Patching: updating is the only real protection

GitLab offers no workaround for CVE-2026-110264. Example for an Omnibus installation on Debian/Ubuntu (replace gitlab-ee with gitlab-ce depending on your edition):

1. Check the installed version 

sudo gitlab-rake gitlab:env:info | grep -A2 "GitLab information"
Enter fullscreen mode Exit fullscreen mode

2. Back up before doing anything 

sudo gitlab-backup create
sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /root/
Enter fullscreen mode Exit fullscreen mode

The backup does not include gitlab.rb or gitlab-secrets.json: copy them separately.

3. Update 

sudo apt-get update
sudo apt-get install gitlab-ee
Enter fullscreen mode Exit fullscreen mode

If your instance is several versions behind, follow GitLab's official upgrade path rather than jumping straight to the latest version.

4. For Docker, change the image 

docker pull gitlab/gitlab-ee:19.5.1-ee.0
docker compose up -d
Enter fullscreen mode Exit fullscreen mode

Adjust the tag to your branch and edition.

5. Check that the fix is active 

sudo gitlab-rake gitlab:env:info | grep -A2 "GitLab information"
sudo gitlab-ctl status
Enter fullscreen mode Exit fullscreen mode

Plan ahead: on a single-node server, versions 19.4.3 and 19.3.6 include database migrations that make GitLab unavailable during the operation. Multi-node installations can follow the zero-downtime upgrade procedure.

Security advice to follow

Before updating

  • Take inventory of every GitLab instance, including test or forgotten servers.
  • Handle internet-facing instances first , especially those with public projects.
  • Take a snapshot or full backup so you can roll back.

While waiting for the fix

  • Disable open sign-up for new users.
  • Restrict anonymous access to public projects and prevent untrusted users from creating or editing projects.
  • If possible, limit access to the instance to a VPN or known IP addresses.
  • If your instance uses SAML with automatic LDAP linking, review recent sign-ins and newly linked accounts, in light of CVE-2026-15723.

These measures reduce the attack surface, but do not fix the flaws.

After updating

  • Monitor logs : repeated worker crashes or bursts of errors when rendering .org files are red flags. The two detection rules published by GitLab target exactly these cases.
  • Look for signs of compromise on instances exposed before the fix: unusual processes started by the git account, recent files in GitLab directories, recently created accounts or access tokens, abnormal outbound connections.
  • If in doubt, rotate secrets : CI/CD variables, personal and project access tokens, deploy keys, runner registration tokens.

A shared component, a shared risk

As with PHP2Shell the same week, the defect does not come from business code, but from a core component everyone uses without thinking about it: here, Ruby's regular expression engine. A flaw in such a deep building block can stay hidden for years, then hit every version of a product at once.

What now?

If you updated GitLab on October 12, do it again today. And ask yourself one question: do you know exactly how many GitLab instances run in your organization?

Sources: GitLab – October 21 advisory · The Hacker News · Rapid7 · Help Net Security · Cyber Security News · HOL