Last updated: October 29, 2026
CVE-2026-110264 is a maximum-severity (CVSS 10.0) bug in self-managed GitLab that lets an attacker run code on the server without logging in, and it has been present in every release since GitLab 7.0 in 2014. It is fixed in GitLab CE and EE 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. Why it matters beyond IT teams: code servers like GitLab are where wallets, nodes and privacy tools are built and released, so a hacked code server is a path to a poisoned download. The defence for users hasn't changed: verify signatures, not just the website you got the file from.
- 10.0 CVSS — maximum severity
- 12 years in every release since 7.0
- 2,700+ exposed GitLab CE servers
- 3 critical GitLab bugs since September
What is CVE-2026-110264?
GitLab is a platform for hosting code, reviewing changes and running build pipelines. Companies and open-source projects install it on their own servers ("self-managed"). The bug is in Onigmo, the regular-expression engine of the Ruby language that GitLab bundles and patches in its own builds. An integer overflow in the regex compiler lets a specially crafted regular expression end in arbitrary code running on the server, and no account is needed. GitLab hasn't published the exact conditions yet.
Because Onigmo has been part of GitLab since version 7.0, all releases from the last 12 years are affected. Four of the patched branches are already out of support; GitLab made an exception and backported the fix because of the severity. No attacks have been seen so far, but the Shadowserver Foundation counts more than 2,700 GitLab Community Edition servers reachable from the internet.
Three critical GitLab bugs in two months
| CVE | When | Impact |
|---|---|---|
| CVE-2026-85706 | September 2026 | Unauthenticated reading of arbitrary files on the server (CVSS 10.0) |
| CVE-2026-97229 | Mid-October 2026 | Remote code execution (CVSS 10.0); fixed only in 19.2 and newer |
| CVE-2026-110264 | Late October 2026 | Unauthenticated remote code execution via Onigmo (CVSS 10.0) |
Admins who updated in mid-October for the previous bug have to update again.
Why crypto users should care
Open-source wallets, node software and privacy tools are written, built and released through code platforms. Some projects run their own GitLab, for example the Tor Project's gitlab.torproject.org, which hosts Tor Browser development. Whoever controls a code server can, in principle, slip changes into source code, build pipelines or release files, and from there into the app on your computer. That is a supply-chain attack, and crypto has seen it before without any GitLab bug:
- Monero, November 2019: the CLI wallet download on the official site was briefly swapped for a version that stole funds. A user caught it because the file's hash didn't match the signed list.
- Ledger Connect Kit, December 2023: a malicious version of a JavaScript library was published after a former employee's account was phished, and it injected a wallet drainer into many web apps for a few hours.
In both cases, users who checked signatures, or confirmed every transaction on a hardware wallet screen, were protected.
How to protect yourself as a user
- Verify signatures and hashes of every wallet download and update — the step-by-step guide is in how to verify a crypto wallet download.
- Prefer projects with reproducible builds and several independent signers. Bitcoin Core, for example, publishes hashes signed by multiple builders.
- Confirm on the device. A hardware wallet shows the real address and amount, so tampered software can't silently redirect funds.
- Don't rush big moves right after an update. If a release looks odd, wait for the project's announcement channels to confirm it.
- Beware of "security update" messages. Vulnerability news is used as bait for fake downloads — see phishing emails and SMS.
If you run GitLab
- Update now to 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 or 18.11.13, even if you patched in mid-October.
- Look for exploitation attempts with GitLab's two new detection rules, "Onigmo native worker crash" and "Org mode render error burst", from its open-source TLDR framework.
- Don't keep hot keys in CI. Deploy keys, signing keys and wallet keys stored as pipeline variables are the first thing an attacker on the server takes. Use separate, offline signing.
- Take the instance off the public internet if only your team uses it: a VPN or allow-list removes most of the risk from the next bug.
Frequently asked questions
What is CVE-2026-110264?
A critical (CVSS 10.0) bug in self-managed GitLab CE and EE that allows remote code execution without authentication. It comes from an integer overflow in the Onigmo regex engine and affects all versions since 7.0, released in 2014.
Which GitLab versions fix it?
GitLab CE and EE 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. Older unsupported branches got backports because of the severity.
Is the bug being exploited?
No exploitation had been reported at the time of writing. More than 2,700 GitLab CE servers are reachable from the internet, and it's unknown how many are patched.
Can a GitLab bug affect my crypto wallet?
Indirectly. If a project's code or release server is compromised, attackers could ship a tampered wallet. Verifying the developer's signature on every download protects you even if the server was hacked.
Why did the bug go unnoticed for 12 years?
It sits deep in a bundled third-party component, Ruby's regex engine, that few people audit. Old code in widely shared libraries is a common hiding place for bugs, like the Brotli decoder bug fixed the same month.
Verified wallet, verified downloads, then swap without an account on /swap, for example BTC → XMR. Related: the Brotli Node2Shell bug and DNS hijacking of crypto sites.
Sources: Xakep, GitLab detection rules.