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

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.

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

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"

2. Back up before doing anything

sudo gitlab-backup create
sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /root/

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

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

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

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