GitLab has released fixes for CVE-2026-110264, a maximum-severity flaw that can let an unauthenticated user execute code on a self-managed GitLab server. The bug affects every Community Edition and Enterprise Edition release since version 7.0, which shipped in June 2014.
How the Onigmo Regex Flaw Leads to Code Execution
The vulnerability carries a CVSS score of 10.0. It is an integer overflow that occurs while GitLab compiles a specially crafted regular expression. GitLab says that under certain conditions the overflow can let an unauthenticated attacker run code on the server. The company has not said what those conditions are.
The flaw sits in Onigmo, the regular expression engine used by Ruby. GitLab ships Onigmo in its own packages and patches it itself, which is why the exposure reaches back more than a decade rather than being limited to recent releases.
Fixed Versions and Older Backports
GitLab published fixes in versions 19.5.1, 19.4.3 and 19.3.6. It also backported the patch to 19.2.9, 19.1.9, 19.0.10 and 18.11.13. Those backports go further back than GitLab’s usual maintenance policy, an exception the company reserves for severe issues.
The Hacker News noted that an instance patched with GitLab’s October 12 update, which covered only versions 19.2 and later, is vulnerable again to this flaw and needs one of the new releases.
Hosted GitLab Is Already Protected
GitLab.com and GitLab Dedicated are already patched, so the action falls only on organizations running self-managed installations. GitLab credits Johan Carlsson, who reported the flaw through HackerOne.
Exploitation Status and Detection Rules
GitLab has not reported any exploitation of CVE-2026-110264, and the flaw was not in the CISA Known Exploited Vulnerabilities catalog as of October 22. GitLab did publish two detection rules, named “Onigmo native worker crash” and “Org mode render error burst,” that correspond to behavior tied to the flaw.
The Register noted that attackers exploited another maximum-severity GitLab flaw within days of its patch last month. That precedent frames the current window between patch release and potential exploitation.
Why a Server Compromise Reaches Beyond GitLab Itself
Self-managed GitLab servers typically hold source code, CI/CD secrets and deployment credentials. Code execution on such a server could therefore give an attacker access to the repositories and the pipelines that build and deploy software, which is the pathway security researchers describe when they discuss software supply chain attacks.
The Scale of the GitLab User Base
GitLab says it has 50 million registered users and that more than half of the Fortune 100 use the platform. Only a portion of that base runs self-managed servers, but the range of affected versions means any such installation that has not applied the new release is within scope.
Context From Earlier GitLab Security Releases
The overlap between the October 12 release and this one shows how a partial fix can leave older and newer lines in different states. The October 12 update covered 19.2 and later, and the new advisory has to be applied even to servers that took it. The decision to backport to 18.11.13 and other older lines reflects GitLab’s assessment of the severity.
The unresolved detail is the set of conditions needed to turn the integer overflow into code execution. GitLab has withheld them, and without them the practical exploitability of the flaw outside a lab is not publicly known. The company’s detection rules point to crashes of a native worker and bursts of render errors in Org mode content as the observable signs.
Because the underlying engine is shared by Ruby, the case also illustrates how a flaw in a bundled component can carry a very high severity score even though the application code itself is not the source of the defect.
