GitLab regular expression compiler remote code execution (CVE-2026-110264)

GitLab says that, under certain conditions, an unauthenticated user could execute arbitrary code on the GitLab server due to an integer overflow when compiling a specially crafted regular expression. The CVSS vector is network, low complexity, no privileges, no user interaction and a changed scope, with high impact on confidentiality, integrity and availability.

GitLab has not published a technical description. The release page names two detections, "Onigmo native worker crash" and "Org mode render error burst", but does not say how the attack works. GitLab makes issue details public 90 days after a release. Ruby's announcement of 23 October ties this CVE to an overflow of internal IDs in a Ruby pattern with many repeats. The fix is in Ruby 4.0.9, 3.4.12 and 3.3.13.

A GitLab server holds source code, CI variables and deployment keys, so code execution on it can reach every system built from that code.

In Brandefense's dark web and Telegram monitoring, we found 13 posts naming this CVE, in 13 channels, between 21 and 22 October 2026. All repeat the advisory or news coverage.

From 23 to 28 October 2026 we found five more posts in our dark web and Telegram monitoring, all on Telegram. They are news reposts and automatic feeds that list new GitHub repositories. On X we collected 80 posts from the evening of 23 October to the morning of 28 October, when our collection limit was reached. Most came from outlets and accounts sharing the advisory and the Ruby fixes.

On 28 October GitHub search lists 13 repositories for the CVE id. The newest was created on 24 October and the latest push was on 27 October. By their own descriptions, five are defensive version checkers or scanners, and most of the others are reproduction labs or crash-level studies, several of them saying they are not weaponised. One, created on 22 October and called a "benign PoC carrier", holds no files.

One proof of concept says it was validated on a GitLab 19.3.1 test server. In its lab tests of 22 October, a request for a large Org-mode file made the server answer in about 10 to 19 seconds. A normal file took 0.1 to 0.2 seconds. The same write-up says its code-execution half is at "oracle" level, not yet a shell.

Another repository, last updated on 25 October, says it reached a controlled memory write in its own lab. It also says that on 24 October it still found no public technique for reaching code execution. These are the authors' own claims. We read the descriptions and write-ups and did not run any code.

GitLab CE and EE, all deployment types, in these ranges: 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. Fixed in 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 and 19.5.1.

Servers patched on 12 October to 19.4.2, 19.3.5 or 19.2.8 are still affected. GitLab.com is already patched, and GitLab Dedicated tenants on 19.3.5-internal0 and 19.4.2-internal0 or later need no action. The CVE record names no fix for branches older than 18.11, so those installs need an upgrade to 18.11.13 or later. Each of these fixed versions is newer, by version number, than the fix for the unauthenticated file read CVE-2026-85706 in GitLab, which CISA lists in KEV, so patching for this CVE also covers that one.