A GitLab vulnerability with the highest possible severity score affects self-managed servers going back to 2014. The fix has been out since Wednesday. GitLab shipped seven patch releases on October 21 to close the flaw, tracked as CVE-2026-110264. Under certain conditions, the company says in its patch release notes, an unauthenticated attacker could run arbitrary code on the GitLab server.
No attacks have been reported so far. GitLab itself reports no sign of exploitation, and as of October 22, the bug was not in CISA’s Known Exploited Vulnerabilities catalog, according to The Hacker News. That is the good news. The less comfortable part is that GitLab has not said what the “certain conditions” are, so an administrator cannot rule out exposure by checking a setting.
What the GitLab vulnerability does
The flaw is an integer overflow. It happens when GitLab compiles a specially crafted regular expression, the kind of pattern a program uses to match text. The Hacker News traces it to Onigmo, the regex engine built into Ruby, which GitLab ships and patches in its own packages. Because that code has been there for a long time, every self-managed release back to version 7.0 is affected.
An attacker does not have to log in first to exploit this GitLab vulnerability. That is what puts the score at 10.0, the top of the scale. No account and no stolen password are needed.
The report came through HackerOne from a researcher who goes by joaxcar. The Hacker News says it is the fourth code-execution bug that researcher has reported in GitLab’s regex engine in a month. It is also the first of the four to reach versions older than 19.2.
The October 12 release fixed a close relative, CVE-2026-97229, also scored 10.0 and also an unauthenticated overflow in the regex compiler. The Hacker News says that update covered only 19.2 and later, so older installations were left without a fix until this week. Two more flaws, both scored 9.9, were fixed on September 23. Those needed a logged-in account.
Which versions to install
GitLab fixed seven versions at once: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. Four of those, 18.11 through 19.2, are backports outside GitLab’s usual support window, which covers the current monthly release and the previous two. The company reserves that step for severe problems.
If you run something older than 18.11, the notes say every version from 7.0 is affected. The practical path there is an upgrade to a fixed branch, not a patch to the old one.
GitLab.com already runs the fixed code. GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 or later have it too. Only self-managed installations need to act.
Plan for downtime if you run a single server. GitLab’s notes say single-node instances will go offline during the upgrade because database migrations have to finish before the service starts. The 19.4.3 and 19.3.6 releases carry regular migrations. Multi-node installations can follow GitLab’s zero-downtime procedure instead.
There is no workaround
GitLab’s advisory offers no interim fix for this GitLab vulnerability. The Hacker News is blunt about it and calls the patch the only certain protection. Turning off a feature or tightening a firewall rule is not listed as a substitute, and since the triggering conditions are unexplained, nobody can say which setting would help.
For teams that cannot patch today, GitLab published two detections in Sigma format as part of its open-source TLDR framework. One looks for an Onigmo native worker crash. The other looks for a burst of Org mode render errors. They run against GitLab’s application logs. They are alarms, not blocks, and they only help if someone is watching the alerts.
GitLab also notes that details of the fixes become public 90 days after release. That is a clock. Once the technical write-ups appear, copying the approach gets much easier for anyone who wants to try.
What else is in the October 21 release
GitLab’s table lists 12 CVEs for the release. One is critical. Two are rated high. CVE-2026-15723 is an account takeover that needs both SAML and LDAP auto-linking switched on, and CVE-2026-112212 is a cache-poisoning bug in the OAuth and OpenID Connect discovery endpoints that could redirect some sign-in flows to an attacker’s server in setups with a shared cache.
The remaining nine are medium or low. They include a weak billing check that let some users reach paid AI features, and a merge request approval policy bypass on protected branches. They matter less than the critical bug, but they ride along in the same upgrade.
Why speed matters for this GitLab vulnerability
Repeat bugs in one component are a pattern worth noticing. Two regex-compiler overflows, both scored 10.0, have now been fixed nine days apart, and The Hacker News counts two more code-execution bugs from the same researcher in the same engine over the past month. Researchers tend to keep digging once they find a productive seam, and they are not the only ones reading the changelog.
Our look at an AI-assisted Chrome exploit built in six days for about $40,000 is one data point on how cheap exploit development is getting. We also covered how hackers chained three Ivanti zero-days to take root on a fully patched VPN, a reminder that internet-facing, self-hosted software is where attackers go first.
What to do today
Start by finding your version to see whether the GitLab vulnerability applies to you. The help page in the GitLab web interface shows it. Match it to the list above, schedule the upgrade, and book downtime if you are on one node. After that, switch on the two detections and look back through your logs for the crash and render-error patterns.
If your GitLab instance sits on the open internet, it is worth asking whether it has to. Putting it behind a VPN or an allowlist will not replace the patch, but it shrinks the number of people who can send the server a malicious pattern.
Editor’s take
The patch for the GitLab vulnerability is out and the exploit, as far as anyone has reported, is not. That gap is the whole story, and it will not stay open. GitLab did the right things: it fixed seven branches, including four it was not obliged to touch, and it shipped detections in the same release. What it has not done is explain the conditions, and until it does, the safest assumption is that every self-managed instance is in scope. Patch this week, not at the next quarterly window.
