On October 21, 2026, GitLab shipped an out-of-band critical patch release. It closes twelve security vulnerabilities, the most dangerous of which is CVE-2026-110264. We call it "RegExplode". A flaw in GitLab's regular expression compiler lets attackers without a user account execute arbitrary code on the GitLab server under certain conditions. GitLab rates it at the maximum score of CVSS 10.0.
If your company runs its own GitLab instance, this update should not wait for the next maintenance window.
What happened?
GitLab uses regular expressions (regex) in many places, for example when rendering content and evaluating configuration. The responsible regex compiler contains an integer overflow: a specially crafted expression causes a numeric value to wrap around and corrupts memory. According to GitLab, an unauthenticated attacker can use this to run code on the server. The issue was reported through GitLab's bug bounty program on HackerOne.
The fix includes, among other things, patches to Ruby's regex engine, which GitLab is built on. GitLab does not list a workaround that avoids updating.
The backstory matters: only on October 12, 2026, GitLab closed a different regex vulnerability with CVSS 10.0 (CVE-2026-97229, in CI/CD configuration). According to Rapid7, a public proof of concept already exists for that earlier flaw. Two maximum-severity vulnerabilities within ten days show that security researchers are taking a close look at this part of GitLab right now, and attackers most likely are too.
The same release contains further relevant fixes, including:
- CVE-2026-15723 (CVSS 8.2): account takeover when SAML and LDAP auto-linking are both enabled.
- CVE-2026-112212 (CVSS 7.5): cache poisoning of the OAuth/OIDC discovery document, which can redirect sign-in flows to an external server.
Who is affected?
Affected are self-managed installations of GitLab Community Edition (CE) and Enterprise Edition (EE), whether on your own hardware, in a VM or in a container. GitLab has already patched GitLab.com and GitLab Dedicated itself.
| Release line | Fixed in |
|---|---|
| 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 |
| 18.11 | 18.11.13 |
| older than 18.11 | no fix, upgrade required |
As of October 22, neither GitLab nor the security press reported active exploitation, and no public exploit was known. However, the Shadowserver Foundation tracks around 2,700 GitLab CE instances that are directly reachable from the internet, which shows how many systems could become targets.
For businesses, a GitLab server is a particularly valuable target: it holds source code, CI/CD pipelines, credentials for servers and cloud accounts, and often deployment keys for production. Whoever takes over GitLab frequently gains a path into the rest of the infrastructure.
What you should do now
- Check your version: as an administrator under Help → Help (
/help) or withsudo gitlab-rake gitlab:env:infoon the server. - Create a backup: before updating, run a fresh backup (
sudo gitlab-backup create) and also save/etc/gitlab/gitlab.rband/etc/gitlab/gitlab-secrets.json. - Update immediately to the matching version from the table: via your distribution's package manager for the Omnibus package, or via the new image tag for Docker. Note: 19.4.3 and 19.3.6 include database migrations. Single-node instances will be briefly unavailable during the update, while multi-node installations can be upgraded without downtime.
- Older versions (before 18.11): there is no patch. Plan the upgrade along GitLab's official upgrade path, as versions cannot be skipped arbitrarily.
- Reduce the attack surface: where possible, expose GitLab only via VPN or zero-trust access, and disable open self-registration if you do not need it.
- Review logs: GitLab has published detection rules, among others for crashes of the "Onigmo native worker" and bursts of "Org mode render errors". If you see such patterns from the last few days, treat the system as potentially compromised and rotate tokens, runner registrations and credentials stored in CI/CD.
How Sadeem helps
We operate GitLab, CI/CD pipelines and the servers behind them for small and mid-sized businesses, fully hosted in Germany or the EU if you prefer. We review your installation, roll out updates in a controlled way with a backup and rollback plan, and secure access so that internal tools are not exposed on the open internet. With managed hosting, you do not have to act yourself when the next critical vulnerability appears.
Not sure whether your GitLab is affected? Talk to us in a free initial consultation.