GitLab released a critical patch on 21 October 2026 for CVE-2026-110264. It can let an unauthenticated attacker run code on a self-managed GitLab server, 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 22 October 2026. We will add new facts as GitLab or other sources publish them.
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.
| Your branch | Affected until | Fixed in | Fixed on 12 October? |
|---|---|---|---|
| 19.5 | before 19.5.1 | 19.5.1 | Not applicable (not yet released) |
| 19.4 | before 19.4.3 | 19.4.3 | 19.4.2 is still affected |
| 19.3 | before 19.3.6 | 19.3.6 | 19.3.5 is still affected |
| 19.2 | before 19.2.9 | 19.2.9 | 19.2.8 is still affected |
| 19.1 | before 19.1.9 | 19.1.9 | No fix on 12 October |
| 19.0 | before 19.0.10 | 19.0.10 | No fix on 12 October |
| 18.11 | before 18.11.13 | 18.11.13 | No fix on 12 October |
| 7.0 to 18.10 | all versions | Upgrade to 18.11.13 or later | No fix on 12 October |
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.
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.
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.
The bug fix lists for 19.5.1, 19.4.3, 19.3.6 and 19.2.9 each include an entry about a Ruby regular expression overflow patch. GitLab does not link that entry to this CVE. We read it as a hint that the fix sits in the Ruby regular expression engine, but that is our reading, not GitLab’s statement.
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. Our external attack surface management guide explains how.
What If You Cannot Patch Tonight?
We found no workaround in GitLab’s 19.5.1 notes and no government advisory for this CVE as of the morning of 22 October. CISA’s Known Exploited Vulnerabilities catalog lists neither this CVE nor CVE-2026-97229. 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. No source says they cover the new 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.
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, as of the morning of 22 October (UTC).
- 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
- 0GitHub repositories found for the new CVE idSource: 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. We found no post that reports confirmed exploitation of this flaw, and none that offers a working exploit. 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. None offers access to a GitLab server for sale, and none discusses scanning. That fits a flaw with no public exploit yet. It does not mean attackers are idle, because private work leaves no trace in public chats.
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. For CVE-2026-110264, GitHub’s own search returned none when we checked.
Our assessment, based on the 12 October pattern, is that public proof-of-concept code for this flaw is likely within days. That is a judgment and not a measurement. 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. Unverified exploit repositories are a common way to infect the people who look for them.
- 12 Oct 2026GitLab patches CVE-2026-97229Versions 19.4.2, 19.3.5 and 19.2.8, CVSS 10.0.
- 13 Oct 2026Rapid7 publishes its alertIt links a proof-of-concept repository and reports no confirmed exploitation in the wild.
- 13 Oct 2026CVE-2026-110264 is reservedThe CVE record shows the reservation date.
- 16 Oct 2026Rapid7 publishes its technical analysisIt details one exploit route for CVE-2026-97229.
- 21 Oct 2026GitLab ships 19.5.1 and backportsFix for CVE-2026-110264, CVSS 10.0.
- 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.