GitLab fixes CVSS 10 flaw enabling unauthenticated code execution back to version 7.0
GitLab released critical patches for CVE-2026-110264, an integer overflow in its regex compiler that could let unauthenticated attackers run code on self-managed servers.
At a glance
- CVE-2026-110264 (CVSS 10.0) is an integer overflow in the regular expression compiler that can lead to unauthenticated code execution.
- All self-managed GitLab CE/EE versions from 7.0 onward are affected; fixes are in 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13.
- GitLab.com is already patched; GitLab reports no exploitation so far and offers no workaround.
- Instances patched on October 12 for a similar flaw must be updated again.
GitLab released a critical patch on October 21, 2026 for CVE-2026-110264, a maximum-severity (CVSS 10.0) vulnerability that could allow an unauthenticated user to execute arbitrary code on self-managed GitLab servers. According to GitLab's advisory, the flaw is an integer overflow in the regular expression compiler, triggered when a specially crafted regex is compiled, and it affects every version from 7.0 onward, meaning roughly twelve years of releases.
What happened
GitLab shipped fixed versions for seven release lines at once: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13, for both Community and Enterprise Editions. According to The Hacker News, four of these lines are older than GitLab's normal support window, which covers only the current and two previous monthly releases, and the company backported the fix as an exception reserved for severe issues.
The Hacker News reports that the vulnerable code is GitLab's own patched copy of Onigmo, the regex engine built into Ruby, which explains why the weakness reaches back to version 7.0. The publication credits a researcher using the handle joaxcar and says this is the fourth code-execution bug in GitLab's regex engine reported by the same researcher in about a month.
The issue follows CVE-2026-97229, another unauthenticated CVSS 10.0 overflow in the same compiler that GitLab fixed on October 12. According to The Hacker News, that earlier flaw affected only 19.2 and later, so administrators who patched on October 12 remain exposed until they move to the new releases.
Technical details
GitLab has not disclosed the conditions an attacker needs to reach the vulnerable compiler, and The Hacker News notes that administrators therefore cannot rule out exposure through configuration. The advisory provides no interim workaround. GitLab did publish two detections for self-managed administrators, named "Onigmo native worker crash" and "Org mode render error burst", which can help spot exploitation attempts.
The release fixes 11 security issues in total. Among them, according to GitLab:
- CVE-2026-15723 (CVSS 8.2): an authenticated user could take over an existing LDAP-backed account when both OmniAuth SAML and LDAP auto-linking are enabled.
- CVE-2026-112212 (CVSS 7.5): an unauthenticated user could poison a shared cache of OAuth/OIDC discovery documents to redirect authentication flows to an external server.
Who is affected
Only self-managed GitLab installations need action. GitLab.com already runs the fixed code, and GitLab Dedicated tenants on 19.3.5-internal0, 19.4.2-internal0 or later already include the fix. GitLab says it has seen no signs of exploitation, and The Hacker News notes the flaw was not in CISA's Known Exploited Vulnerabilities catalog as of October 22. However, previous GitLab critical flaws have attracted attackers quickly, and source code servers often hold credentials and CI/CD secrets.
What to do
GitLab strongly recommends upgrading all self-managed instances immediately to the patched version for their release line. Versions 19.4.3 and 19.3.6 include database migrations, so single-node servers will experience downtime while migrations finish; multi-node deployments can follow GitLab's zero-downtime upgrade procedure. Administrators should also deploy the two published detections and review logs for unexplained worker crashes. Internet-facing instances should be prioritized.
Related CVEs
Sources
This story is based on the sources listed above. Always check the vendor’s official advisory before acting on critical systems.



