GitLab's Second 10.0 RCE This Month. Your October 12 Patch Doesn't Cover It.

On October 12, GitLab told every self-managed admin to patch a 10.0 regex RCE, and the responsible ones did it that day. On October 21, GitLab told them to patch again — because a second 10.0 had landed in the same regex compiler, and the first patch sits exactly one version below the new fix. If your status report says "patched October 12," you are not done — you are the target audience for this post.

The bug, in plain terms

CVE-2026-110264 is an integer overflow that triggers when GitLab's server compiles a specially crafted regular expression. Under "certain conditions" — GitLab's phrase, not mine, and the company has declined to say what those conditions are — an unauthenticated user can execute arbitrary code on the GitLab server.

The CVSS 3.1 vector reads like a worst case assembled from spare parts: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The attack arrives over the network, complexity is low, no privileges are required, no user interaction is needed, and the impact on confidentiality, integrity, and availability is maximal. That is how you land on a flat 10.0, the ceiling of the scale.

The component is the interesting part. The vulnerable code is not in GitLab's application logic — it is in Onigmo, the regular-expression library that lives inside the Ruby runtime GitLab bundles into its own packages. SOC Prime's public reporting points to GitLab's rendering of Org mode as the likely path into the flawed compiler, though GitLab has deliberately held back the precise trigger while operators patch. The researcher credited with finding it goes by "joaxcar" and reported through GitLab's HackerOne bug bounty program.

Why it reaches back to 2014

A flaw in a "regex compiler" sounds like it should be a recent piece of GitLab code. It isn't. GitLab ships its own Ruby in every release, and that Ruby carries Onigmo. So the weakness exists everywhere GitLab has shipped that engine — which is every release since GitLab 7.0, published in 2014. Roughly twelve years of installs, all in range.

The fix list reads like a confession of that history. On the newer branches the patches are titled "Ruby regexp repeat ID overflow" for Ruby 3.3, 3.4, and 4.0; on the older branches they are "repeat-range double-free" patches for Ruby 3.3 and 3.4. The engine is old, the packaging is old, and the bug is old. No "old stable release" position exists here — old branches are where the exposure is widest.

Censys, which scanned for exposed GitLab instances on disclosure day, found roughly 82,000 hosts and about 209,000 web properties running GitLab — and since every release from 7.0 up to the October 21 fixes was affected, that was effectively the entire population. More than half run release lines over seven months old with no fix of their own; over a quarter are three or more majors behind and must step through GitLab's required upgrade stops.

The October 12 patch is the trap

Nine days before this disclosure, GitLab patched CVE-2026-97229 — the same CVSS vector, the same 10.0 ceiling, the same regex compiler. That round shipped as 19.4.2, 19.3.5, and 19.2.8, and it covered only versions 19.2 and later. The new fixes are 19.4.3, 19.3.6, and 19.2.9.

Read those pairs again. 19.3.5 became 19.3.6. 19.4.2 became 19.4.3. Each new fixed version sits exactly one patch above the October 12 build on its branch. A server you upgraded last week to close the first regex RCE is still exposed to the second. As the Suriq advisory put it: patching is not a one-time event here.

That is also the pattern that should worry you more than the CVE itself. Two maximum-severity integer overflows in the same compiler, nine days apart, in a component that has been shipping since 2014. Either GitLab or the researchers are combing that compiler now — and a third find would not surprise anyone. It was also a crowded week for infrastructure software: Amazon confirmed PHP2Shell exploitation attempts four days before that disclosure.

Who has to act — and the version table

First, the people who can stop reading: if you run GitLab.com, the fixed version is already live, and GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later already include the fixes. There is no workaround — upgrade is the only remediation.

Everyone on a self-managed GitLab Community or Enterprise Edition instance, on any deployment type, has work to do:

• If you run 19.5 before 19.5.1 — upgrade to 19.5.1
• If you run 19.4 before 19.4.3 — upgrade to 19.4.3
• If you run 19.3 before 19.3.6 — upgrade to 19.3.6
• If you run 19.2 before 19.2.9 — upgrade to 19.2.9
• If you run 19.1 before 19.1.9 — upgrade to 19.1.9
• If you run 19.0 before 19.0.10 — upgrade to 19.0.10
• If you run 7.0 through 18.11 — upgrade to 18.11.13

Three quirks worth knowing. GitLab normally patches only the three newest minor versions; shipping four backports (19.2, 19.1, 19.0, 18.11) is unusual and a decent signal of how seriously the company takes this. But those backports carry only the critical fix — the other eleven fixes in the same release, including a high-severity LDAP account-takeover (CVE-2026-15723) and an OAuth/OIDC cache poisoning (CVE-2026-112212), require 19.3.6, 19.4.3, or 19.5.1. And the 19.4.3 and 19.3.6 builds include database migrations: a single-node server stays down until they finish, while multi-node installations can use the zero-downtime upgrade procedure.

What to do this week

Start with the inventory, because the forgotten instance is the breach. List every GitLab server you run — Geo secondaries, staging, disaster recovery, test environments. Check the running version on each host (the /help page while signed in, or the version command for your install type) rather than assuming last week's upgrade carried over.

Then patch to the fixed build on your line — a 19.4.2-to-19.4.3 upgrade needs no extra stops, which is the point of the backport table. If you are on a branch older than 18.11, there is no fixed release on your line — plan the stepped upgrade now, because every version in the table is reachable but the path goes through GitLab's required stops.

After patching, treat the instance as potentially compromised and rotate the secrets it held. Censys's advisory is explicit: a breached GitLab server exposes source code, CI/CD secrets, and deploy credentials — the keys to shipping software to production. Run GitLab's two published detection rules over your recent logs while you are at it.

One objection you will hear, and I will answer it now: "but it hasn't been exploited." Correct — GitLab reports no sign of exploitation, it is not in CISA's Known Exploited Vulnerabilities catalog as of October 22, and no public proof of concept existed by then (two GitHub repositories appeared that day; one implemented the sibling CVE by its own author's admission, the other was emptied). But Amazon's disclosure this same week showed PHP2Shell being probed four days before its embargo lifted, because AI-assisted analysis has made turning a patch into a working exploit much cheaper. Patch timelines for critical internet-facing systems are now measured in hours. That is also the honest counterpoint to the headline's comfort: the researchers found this one privately. The next one may not wait.

And one housekeeping note for anyone keeping score: this is a different bug from the GitLab AI Gateway sandbox escape I covered earlier in October. Two 10.0-class flaws, two components, same month. The regex compiler is the one that affects twelve years of your servers. Start there.

References

• Critical GitLab Flaw (CVSS 10.0) Could Allow Unauthenticated RCE Across 12 Years of Releases — The Hacker News
• GitLab CVE-2026-110264: Critical Unauthenticated RCE in Self-Managed GitLab CE/EE — Rescana
• CVE-2026-110264 Advisory — Censys Rapid Response
• GitLab CVE-2026-110264 RCE: Fixed Versions — Suriq
• GitLab Critical Patch Release 19.5.1 — Konfirmity
• GitLab CVE-2026-110264: Patch Critical Unauthenticated RCE — WindowsForum (BleepingComputer reporting)