On October 12, GitLab shipped a critical patch for a CVSS 10.0 regex engine RCE. Ten days later, on October 21, they shipped another one: a different bug in the same regex engine, reported by the same researcher who found the first.
If your team upgraded on the 12th and marked the ticket resolved, you are exposed again today. If you planned to batch-patch at month-end, that plan now has two critical holes.
The practical question is which version to upgrade to. The harder question is why the same subsystem keeps producing CVSS 10s, and whether the next one is already sitting in someone’s inbox.
What happened with GitLab on October 21, 2026? (TL;DR)
GitLab disclosed CVE-2026-110264, an integer overflow in the Ruby regex compiler that GitLab runs on. An attacker who can reach the server can execute code without a login or token.
The fast facts:
- Affected: every self-managed CE and EE release from 7.0 (June 2014) through the fixed versions
- Fix: 19.5.1, plus six back-branch releases (19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13)
- Not affected: gitlab.com SaaS and GitLab Dedicated already patched
- Status: no confirmed exploitation as of October 22, not yet in CISA’s KEV catalog
A CVSS 10 pre-auth RCE doesn’t stay quiet for long. Treat this as patch-now and read the rest for the why.
How does CVE-2026-110264 work?
The flaw is not in GitLab’s Rails code, but in Onigmo – the Ruby regex engine that sits underneath GitLab. The Ruby runtime shipped a patch titled “repeat ID overflow” for versions 3.3, 3.4, and 4.0; that’s the actual root cause, and GitLab is just the biggest downstream victim.
Here’s what “repeat ID overflow” means without the compiler jargon:
- Onigmo compiles each regex pattern it receives and assigns a numeric ID to every repetition group inside it (think (abc){5} or nested quantifiers).
- Those IDs live in a finite-range counter.
- A pattern crafted with the right number of nested repetitions overflows the counter.
- The overflow lets the attacker write into memory the regex compiler was never supposed to touch.
- Memory corruption on a running web server, as a rule, ends with code execution.
Imagine a parking garage with 65,536 numbered slots and a barcode scanner that reads ticket numbers directly as slot addresses. Hand in ticket number 65,537 and the scanner wraps around to slot zero. The car it hands you back belongs to someone else.
The “unauthenticated” part comes from where the regex compiler sits in GitLab’s request path. GitLab accepts rendered content from anyone who can reach the login page:
- File previews
- Org mode files
- Wikis
- Markdown blobs
- Project READMEs
Any of these paths can hand attacker-controlled text to Onigmo. GitLab’s detection rules name the attack surface directly: one is called “Onigmo native worker crash,” the other “Org mode render error burst.” If you were wondering where to look in your logs, those are the breadcrumbs.
Why does GitLab keep getting hit with regex RCEs?
This is the fourth regex-engine RCE in GitLab in roughly a month. All four were reported by the same researcher, joaxcar, through HackerOne. When one person finds four bugs of the same class in the same subsystem within thirty days, two things are true: the subsystem is a target now, and the researcher has calibrated their fuzzer to it.
That matters for how you plan the next quarter. The regex engine is in an active disclosure cycle, which is a different problem to plan for than a one-time patch. The fifth bug in this run, if it lands, will probably arrive before you’ve finished rolling out this one.
Who is affected by CVE-2026-110264?
- Self-managed GitLab CE and EE: every version from 7.0 (released June 2014) up to the fixed releases. If you have an instance anyone has ever forgotten about, assume it’s vulnerable.
- gitlab.com SaaS: already patched. Nothing for you to do.
- GitLab Dedicated: tenants on 19.3.5-internal0 or 19.4.2-internal0 and later were patched ahead of public disclosure.
- CISA KEV status: not listed as of October 22. No confirmed real-world exploitation yet. That window usually closes within days for a pre-auth RCE at CVSS 10.
The eleven-year back-catalog matters more than it sounds. Teams running old self-managed instances for compliance or legacy reasons tend to assume they’ve been quietly fine. They haven’t been. They’ve been one bad regex away from a shell this whole time.
What other CVEs did GitLab fix in 19.5.1?
The RCE is the reason to upgrade this week. These are the reasons to actually read the release notes.
| CVE | Severity | What it does |
| CVE-2026-110264 | Critical (10.0) | Pre-auth RCE in the regex compiler |
| CVE-2026-15723 | High (8.2) | LDAP account takeover via OmniAuth-to-LDAP auto-linking |
| CVE-2026-112212 | High (7.5) | OAuth/OIDC discovery cache poisoning |
| CVE-2026-12664 | Medium (6.8) | GraphQL field bypasses read_api token scope |
| CVE-2026-16255 | Medium (5.9) | SAML/LDAP membership lock bypass (EE only) |
| CVE-2026-105777 | Medium (4.3) | Internal server credentials leaked in headers |
| CVE-2026-13319 | Medium (4.3) | Group milestones API leaks private project data |
| CVE-2026-112378 | Medium (4.3) | Paid AI features accessible without a subscription (EE only) |
| CVE-2026-105711 | Low (3.5) | Confidential issue titles leak via MR fragment cache |
| CVE-2026-14288 | Low (3.1) | Required MR approval policies bypassable (EE only) |
| CVE-2026-112326 | Low (3.1) | Read-only users can delete vulnerability records (EE only) |
| CVE-2026-103515 | Low (2.7) | Group Owners can re-enable Duo despite admin lock (EE only) |
The LDAP account takeover and the OAuth cache poisoning deserve a second look. Both chain well with internal access, and both affect anyone with federated login turned on.
How do you patch CVE-2026-110264?
Step 1
Upgrade to the fixed release that matches your current version: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, or 18.11.13. Single-node installations will take some downtime for migrations. Multi-node can go zero-downtime if you follow GitLab’s standard procedure.
Step 2
Restrict network access to the GitLab UI before the upgrade finishes. Firewall, VPN, allowlist, whatever your environment supports. If your GitLab login page is publicly reachable right now, change that first. The patch is the goal; blocking anonymous access is the stopgap.
Step 3
Turn on GitLab’s detection rules published alongside the advisory: “Onigmo native worker crash” and “Org mode render error burst.” They’re the earliest signal you’ll get that someone’s trying.
Step 4
Watch for unusual child processes spawned by GitLab components (Puma workers, Sidekiq, Workhorse). A shell or reverse connection from one of those is not a tuning issue.
Step 5
Confirm the October 12 patch is actually in your current build. CVE-2026-97229 was the previous CVSS 10. Teams that did one GitLab upgrade in October tend to assume they got both. They did not necessarily.
Is patching enough?
Four regex RCEs in a month, from one researcher, in one engine. If this is only the fourth found, how many are left?
Patching is table stakes. The harder question is architectural: should your GitLab instance’s attack surface include a Ruby regex compiler that eats attacker-controlled content from unauthenticated users? For a lot of teams, the answer has been “yes, because that’s how GitLab works.” That answer is fine until the current disclosure cycle stops being charitable.
Network-level isolation is not a workaround for this specific bug; it’s a hedge against the ones that haven’t been reported yet. If your GitLab is reachable from the open internet because nobody got around to putting it behind a VPN, this month is the month to get around to it.
Ten days, two bugs, same door
If you upgraded on October 12 and thought you were done, you weren’t. If you upgrade today, there’s a reasonable chance you still won’t be the next time joaxcar files a report. That’s not pessimism. That’s the current cadence.
Patch to 19.5.1 this week. Get the GitLab login page off the open internet this month. And when the fifth regex RCE lands, as it probably will, you’ll already have the mitigation in place that makes it less interesting.
