GitLab CVE-2026-110264: Am I Affected and What to Do in the Next Hour

On 21 October 2026 GitLab shipped a critical patch release, 19.5.1 with backports, for CVE-2026-110264. The flaw can let an unauthenticated attacker run code on a self-managed GitLab server (remote code execution), and GitLab rates it CVSS 10.0. If you run GitLab yourself, find your version now. Anything older than the fixed version for your branch is affected, even if you patched on 12 October.

GitLab.com and GitLab Dedicated are already patched. This post gives the version table, the order to patch in, what to check afterwards, and what our own data shows about attacker interest so far. The full record is on our CVE-2026-110264 vulnerability page.

Last updated on 29 October 2026. We will add new facts as GitLab or other sources publish them.

Update 28 October: By 28 October, 13 public GitHub repositories name the CVE. The strongest show a slow answer, a worker crash or, in one lab, a controlled memory write. The two most detailed ones say themselves that they stop short of code execution. CISA’s catalog does not list the flaw, and NVD has finished its analysis; details are in the PoC watch below.

Update 23 October: The Ruby project has released Ruby 4.0.9, 3.4.12 and 3.3.13. They fix the Ruby bugs behind CVE-2026-110264 and three earlier GitLab CVEs. The section on what Ruby fixed has the versions and who is affected.

Alpine Reports Attempts to Exploit the Earlier GitLab Flaw

On 28 October, Alpine Linux reported attempts to exploit CVE-2026-97229 against its GitLab instance on 20 and 21 October. This is the earlier October 12 flaw, not CVE-2026-110264. Alpine found no evidence of successful code execution, but could not rule it out and rebuilt the instance; its checks found no tampering with its packages or October 21 releases.

Alpine also found that upgrading its custom container to GitLab 19.3.6 had left the Ruby flaw open. Its image used standard Ruby, so it missed the Ruby patch bundled in GitLab’s official packages. Alpine says its replacement 19.3.6 image, published on 27 October, includes Ruby 3.3.13; earlier copies of that image remain vulnerable.

Am I Affected by CVE-2026-110264?

Only self-managed GitLab Community Edition (CE) and Enterprise Edition (EE) installs are affected. GitLab says that when its notes name no deployment type, all types are affected. That covers Linux packages, Helm charts, Docker images and source installs.

To read your version, sign in, open the Help menu at the bottom of the left sidebar and select Help. The version is shown at the top of the page.

The CVE record lists every version from 7.0 (2014) up to the fixed versions below. Your branch is the first two numbers of your version, so 19.4.2 is on the 19.4 branch.

The last row follows from the CVE record, which ends the affected range at 18.11.13 and names no fix for older branches. GitLab backported the fix to 18.11, 19.0, 19.1 and 19.2 as well as the three newest branches. GitLab has a second CVSS 10.0 flaw in KEV, an unauthenticated file read. Our GitLab file read vulnerability page lists its fixed versions, which are all older than the builds in the table above.

I Patched on 12 October. Am I Safe?

No. On 12 October GitLab fixed a different critical flaw, CVE-2026-97229, in the CI/CD regular expression compiler. It affected only 19.2 to 19.4 and was fixed in 19.2.8, 19.3.5 and 19.4.2. Those versions are each one patch behind the new fixes.

GitLab credits the same researcher for both reports and rates both CVSS 10.0, but its pages do not say the two flaws are the same bug. Ruby’s account of 23 October lists them as different Ruby bugs: a pattern size overflow for CVE-2026-97229 and a repeat ID overflow for CVE-2026-110264.

What Do We Know About the Flaw?

GitLab says that under certain conditions an unauthenticated user could run arbitrary code on the GitLab server, because of 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. The weakness type is CWE-190, integer overflow or wraparound. A good short read on the bug type is our remote code execution entry.

GitLab has not published a technical description. It makes the issue details public 90 days after a release. The 19.5.1 page names two threat detections, “Onigmo native worker crash” and “Org mode render error burst”, but does not explain how the attack works. Do not treat those names as a full picture of the attack path.

On 23 October the Ruby project published its own account. Its announcement says GitLab found bugs in Ruby’s regular expression engine (Onigmo) that could be used for remote code execution on GitLab servers. Ruby 4.0.9, 3.4.12 and 3.3.13 carry the fixes for the bugs behind four GitLab CVEs: CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264.

What Did Ruby Fix, and Are Other Ruby Apps Affected?

Ruby’s announcement ties each GitLab CVE to a Ruby bug. It lists the first release of each Ruby series that has the fix.

GitLab’s 19.5.1, 19.4.3, 19.3.6 and 19.2.9 bug fix lists carry the matching entry for the last row, “Add Ruby regexp repeat ID overflow patch for 3.3, 3.4 and 4.0”. Ruby says GitLab fixed these issues by patching the Ruby it ships. For a GitLab server, the GitLab upgrade is still the fix.

Ruby says the bugs are reached only when an application compiles a regular expression from a string that an attacker controls. Examples are Regexp.new, Regexp.union and Regexp.compile, or building a regexp literal from input. Applications that use only regular expressions written by their own developers are not affected.

Two usual defences do not help, according to Ruby. The Regexp timeout setting does not protect against these bugs. Limiting the length of patterns does not reliably protect either, because some of the bugs can be triggered by short patterns.

Ruby recommends upgrading to 4.0.9, 3.4.12 or 3.3.13 or later. If you cannot upgrade, avoid compiling regular expressions from untrusted input. Ruby 3.3 is in its security maintenance phase, and 3.3.13 includes these fixes as an exception because GitLab assigned CVEs to issues that rely on them. Ruby 4.0.8, released on 22 October, already had the pattern size fix.

Ruby says it has not requested CVE identifiers of its own for these fixes, at least for now. It asks readers to track the issues under GitLab’s four identifiers, for example in a security scanner. Ruby plans to discuss whether it will treat this kind of issue as a Ruby vulnerability.

What Should You Do in the Next Hour?

• Find every self-managed GitLab you runInclude test, staging and old servers that nobody owns any more.
• Rank them by exposureServers reachable from the internet go first, then those behind a VPN, then internal-only ones.
• Back up, then upgrade the first serverMove to the fixed version for your branch, for example 19.4.2 to 19.4.3.
• Confirm the new versionOpen the Help page again and check the number matches the table.
• Look for signs of abuseUse the detection steps below, and keep logs from before the upgrade.

GitLab’s upgrade guidance says to move to the latest patch release of your minor version rather than the first one. If you sit on 18.10 or older, follow the required upgrade stops in GitLab’s upgrade path guide. On GitLab 18 they fall at 18.2, 18.5, 18.8 and 18.11, and older major versions have their own stops, so the first fixed target for you is 18.11.13. Check the upgrade notes for each step.

The same release fixes eleven other issues, including two rated High by GitLab: an LDAP account takeover (CVE-2026-15723) and OAuth discovery cache poisoning (CVE-2026-112212). One upgrade covers them all, which is another reason not to wait for a maintenance window. Patching also belongs in your regular patch management routine, and finding every exposed server is an attack surface task, while vulnerability intelligence tells you which new flaws to treat first. Our external attack surface management guide explains how.

What If You Cannot Patch Tonight?

GitLab’s 19.5.1 notes name no workaround. CISA’s Known Exploited Vulnerabilities catalog lists neither this CVE nor CVE-2026-97229 (checked at 21:24 UTC on 22 October, 00:24 Turkey time on 23 October). At 12:50 UTC (15:50 Turkey time) on 22 October, CISA’s enrichment of the CVE record rated exploitation as “none” and the flaw as automatable.

That means attacks could be repeated at scale. So there is no official stopgap to copy.

For CVE-2026-97229, Rapid7 said two measures can reduce exposure to the path it demonstrated. One is limiting anonymous access to public projects. The other is stopping untrusted users from creating or writing to public projects.

Rapid7 also said these controls do not fix the vulnerable compiler. Rapid7 gave them for CVE-2026-97229, not for this flaw. If you use them, treat them as a few hours of delay and patch as soon as you can.

How Do You Detect Exploitation Attempts?

GitLab says it released two threat detections for self-managed customers: “Onigmo native worker crash” and “Org mode render error burst”. Turn both on if your setup supports them, then review the period since 21 October. The first one also appears in the six detections GitLab listed for CVE-2026-97229.

Rapid7 gives log pointers for its demonstrated chain for CVE-2026-97229. They are a useful starting point, but Rapid7 notes that the undisclosed attack path may differ.

• In the Workhorse log at /var/log/gitlab/gitlab-workhorse/current, look for a CI lint API request that runs for several seconds. It ends in an HTTP 502 with an EOF error.
• Look for a Puma worker that crashes or restarts at the same moment, and for a saved trace that mentions regexp_matcher.rb.
• A shell process started by the GitLab worker, or a jump of about 2 GiB in worker memory, makes a match stronger.

If you find a match, treat the server as compromised. Assume the attacker can read source code, CI variables and tokens, rotate them, and rebuild the server from a known good image.

For this CVE, one public write-up reports lab tests from 22 October on a vulnerable GitLab 19.3.1 test server. Each slow request left an unauthenticated Timeout::Error entry from the Org-mode renderer (OtherMarkup) in GitLab’s exception log, four in its test run. The author suggests alerting on five or more such entries in 30 minutes from one client. It is that author’s claim, so treat it as a hint when you review logs.

Brandefense Analysis: What Our Data Shows So Far

We searched our dark web and Telegram monitoring, public posts on X and GitHub repository metadata. We did not open, download or run any exploit code. Below are counts and themes only. The figures are as of the morning of 22 October (UTC), and a repeat check at 21:21 UTC follows them.

• 336Unique public X posts about the release, from 18:58 UTC on 21 October to 08:09 UTC on 22 OctoberSource: Brandefense threat intelligence data, 21 to 22 October 2026
• 39Posts in the busiest hour, 22:00 UTC on 21 OctoberSource: Brandefense threat intelligence data, 21 to 22 October 2026
• 9Telegram posts naming CVE-2026-110264, in nine different channelsSource: Brandefense threat intelligence data, 21 to 22 October 2026
• 1Public GitHub repository named as a PoC for the new CVE id: created 08:31 UTC, no files at 08:49 UTCSource: Brandefense threat intelligence data, 21 to 22 October 2026

Attention was fast and wide. Of the 336 X posts, 323 mention GitLab and 127 name the CVE id. About two thirds are in English (228), and 46 are in Japanese.

The posts are mostly advisory shares and patch warnings. One reply says a self-hosted GitLab was exploited at some point, with no CVE or detail, and we could not verify it. We did see posts that promote a crypto token named after the CVE. Treat such posts as scams.

The nine Telegram posts, all from 21 and 22 October, are repeats of the advisory or of news coverage.

We repeated the searches at 21:21 UTC (00:21 Turkey time, 23 October). From 08:00 to 21:20 UTC on 22 October we found 119 unique X posts, and 98 of them name the CVE id. Where posts say “exploited”, they mean the two PHP flaws disclosed the same week, or they describe what could happen.

A repeat Telegram search covering 22 October found nine posts naming CVE-2026-110264, in nine channels. Five were already in our first count and four are new, so we have now seen 13 posts in 13 channels since 21 October. All repeat the advisory or news coverage.

The October 12 flaw gives a useful comparison. We found 23 posts for CVE-2026-97229 in our dark web and Telegram monitoring between 12 and 22 October, and 13 of them came on the first two days. Six pointed to public proof-of-concept code or reported on it, and the other 17 repeated advisories or news.

GitHub search metadata shows three repositories claiming a proof of concept for CVE-2026-97229 between 13 and 17 October. The first appeared on the morning of 13 October (UTC), within about a day of the patch. One of the three is the repository Rapid7 links from its own alert.

The other two we could not verify. The first repository named as a proof of concept for CVE-2026-110264 appeared at 08:31 UTC on 22 October, the day after the patch release. It held no files when we checked; see the PoC watch below.

On 22 October our assessment, based on the 12 October pattern, was that working public proof-of-concept code was likely within days. Six days later the public repositories show a lab trigger and not code execution. That is no reason to wait for a working exploit before patching.

At 16:43 UTC (19:43 Turkey time) on 22 October, another repository appeared that calls itself a crash-level proof of concept. By its own description, it stops short of code execution; see the PoC watch below. Be careful with any repository you find: do not run code you have not read, and never run it on a machine that holds credentials. Treat any unverified exploit repository as untrusted.

PoC watch: GitHub, 22 October 2026

We check GitHub by metadata only and add a row each time something changes. All times are for 22 October 2026, unless a date is given.

The first repository was empty, and an empty repository is not a working exploit. We do not know why its payload was removed. The 16:43 repository is different, because it holds code and says it crashes the regular expression engine.

By its own description, it stops short of code execution. We do not download or run PoC code. A repository that calls itself a detector is still unverified code: treat it like any other repository you have not read.

Last checked: 22 October 2026, 21:21 UTC (00:21 Turkey time, 23 October).

PoC watch: GitHub, 28 October 2026

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. A request for a large Org-mode file made the server answer in 10 to 19 seconds, against 0.1 to 0.2 seconds for a normal file. Its own write-up says its code-execution half is at “oracle” level, not yet a shell.
• A research 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.
• A repository with “Exploit” in its name says on its own page that its script has not been validated as a working trigger or as an RCE exploit.

These are the authors’ own claims. We read the descriptions and write-ups and did not download or run any code.

We collected 80 public posts on X 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. In dark web and Telegram monitoring we found five posts, all on Telegram: news reposts and automatic feeds that list new GitHub repositories.

The CISA catalog of 27 October (version 2026.10.27) lists neither this CVE nor CVE-2026-97229. NVD marked this record analyzed on the same day.

Last checked: 28 October 2026, 10:00 UTC (13:00 Turkey time).

1. 12 Oct 2026GitLab patches CVE-2026-97229Versions 19.4.2, 19.3.5 and 19.2.8, CVSS 10.0.
2. 13 Oct 2026Rapid7 publishes its alertIt links a proof-of-concept repository and reports no confirmed exploitation in the wild.
3. 13 Oct 2026CVE-2026-110264 is reservedThe CVE record shows the reservation date.
4. 16 Oct 2026Rapid7 publishes its technical analysisIt details one exploit route for CVE-2026-97229.
5. 21 Oct 2026GitLab ships 19.5.1 and backportsFix for CVE-2026-110264, CVSS 10.0.
6. 22 Oct 2026CVE record publishedThe record appeared at 00:33 UTC.

Who Should Treat This as Urgent?

Treat it as urgent if your GitLab is reachable from the internet, or if open sign-up lets strangers create accounts. GitLab holds source code, CI variables and deployment keys, so a code execution bug there is a path into everything built from it. Our earlier post on an exposed GitLab incoming email token shows how one small GitLab secret can become push access to main.

When a stolen key or access listing does turn up, an initial access broker is often the one selling it. Our counts show no such listing for this flaw so far. We will update this post if that changes. Another self-hosted Git server needed urgent fixes on 1 November; see our Gitea 28.3.0 upgrade order and token audit.