GitLab CVE-2026-110264: every version since 7.0, one regular expression.

What GitLab released

On 21 October 2026 GitLab published versions 19.5.1, 19.4.3 and 19.3.6 for Community and Enterprise Edition, carrying twelve security fixes, and backported the critical one to 19.2.9, 19.1.9, 19.0.10 and 18.11.13 — four lines that would normally be outside its security maintenance window.

The CVE record describes the flaw in a single sentence: an issue “affecting all versions from 7.0 before 18.11.13, 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1 that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression.”

GitLab.com was already running the fixed version when the advisory went out, and GitLab Dedicated tenants on 19.3.5-internal0 / 19.4.2-internal0 or later need no action. Every self-managed instance is its owner’s responsibility — and with the hosted platform patched, self-managed servers are what is left to attack.

The release landed on the same day as critical fixes from PHP and Node.js, four days after the eMudhra CA compromise was reported.

What the vulnerability is

GitLab classifies the bug as CWE-190, integer overflow. Ruby’s security team published the underlying detail on 23 October: the defect is in Onigmo, the regular-expression engine built into Ruby, and is an “overflow of internal IDs in a pattern with many repeats”. A counter wraps around while a pattern is compiled, and memory is corrupted when the pattern is later used — which is how an arithmetic bug becomes code execution.

GitLab ships its own patched Ruby inside its packages, so the fix arrives through the GitLab upgrade, not through your operating system’s Ruby. Ruby has released 4.0.9, 3.4.12 and 3.3.13 with the same fixes, but those matter to GitLab only if you build it from source against a system Ruby.

GitLab’s published detection guidance identifies where the vulnerable code is reached: its rendering of Org-mode (.org) markup files, where a regular expression is built from content inside the file. The same guidance says the unauthenticated path needs a public .org file that GitLab renders — which is why instances with public projects, or open self-registration, are the most exposed. GitLab has not published how an attacker without an account places such a file, and neither do we; “under certain conditions” is the honest summary.

The third regex-engine fix in a month

The practical consequence: an instance patched on 12 October for CVE-2026-97229 is still vulnerable to CVE-2026-110264. The earlier fix corrected a different overflow, and the 21 October release is needed on top of it.

Other Ruby applications

Ruby’s advisory is precise about who else is affected: the bugs “are reached only when an application compiles a regular expression from a string that an attacker controls”, through Regexp.new, Regexp.union, Regexp.compile or interpolation such as /#{input}/. Applications that only use patterns written by their developers are not affected. Two warnings in the same advisory are worth repeating: Regexp.timeout “does not protect against these bugs”, and limiting pattern length does not reliably help either. Ruby has not requested its own CVE IDs and asks scanners to track GitLab’s.

Affected and fixed versions

The other eleven fixes in the release

How to find out whether you are exposed

The first thing to know is what you cannot do: read a self-managed GitLab’s version anonymously. The /help page shows the version only to signed-in users, and /api/v4/version returns 401 without a token. An external scan can confirm that GitLab is running and reachable; it cannot honestly tell you the patch level. That answer needs an account, a token or access to the server.

Then list every instance you run, not just the main one. Forgotten GitLab servers — a team’s self-hosted pilot, an acquired company’s instance, a disaster-recovery replica nobody upgrades — are exactly the ones still sitting on 18.x. Certificate-transparency logs and DNS history find them faster than an internal survey does.

Looking for attempts

GitLab published detection rules alongside the advisory (linked in the sources below). One looks for a native Ruby crash with Onigmo frames in puma_stderr.log; another for a burst of render time-outs on .org files from a single client in exceptions_json.log. GitLab is explicit that a crash only corroborates: a successful exploit “is quiet and does not reliably crash”, and the absence of a hit “never clears an attempt or a success”.

If anything suggests code ran, GitLab’s guidance is to treat the instance as compromised: rotate the secrets in gitlab-secrets.json, CI/CD variables, runner registration tokens and access tokens. A GitLab server holds the keys to every pipeline it runs, so the blast radius is your deployment estate, not one application.

If you cannot patch tonight

The CVE record lists no workaround; upgrading is the fix. Until then:

• Reduce public visibility where you can — GitLab’s own interim advice, because the unauthenticated path needs a public .org file.
• Restrict the Public visibility level under Admin → Settings → General → Visibility and access controls, and turn off open self-registration.
• Put the instance behind VPN or single sign-on, so anonymous users cannot reach it at all.
• Make sure puma_stderr.log, exceptions_json.log and the Workhorse log are being collected, so the detection rules have something to read.

Exploitation status, as of 23 October 2026

CVE-2026-110264 is not in CISA’s Known Exploited Vulnerabilities catalogue, and no official source reports exploitation in the wild. CISA’s assessment, however, reads: exploitation “none”, automatable “yes”, technical impact “total”. That combination — no authentication, automatable, full control — is the profile that tends to be weaponised quickly.

About ten public GitHub repositories reference the CVE. By their own descriptions the most prominent is a crash-level, non-weaponised proof of concept; the rest are version checkers, detectors and lab setups. No confirmed public remote-code-execution exploit existed on 23 October.

How SemperWise helps