Critical Maximum-Severity Vulnerability Exposes GitLab Self-Managed Servers Dating Back to 2014

GitLab has issued emergency security updates to address a maximum-severity, unauthenticated remote code execution vulnerability that impacts nearly every self-managed version of its software released over the past twelve years, dating all the way back to version 7.0 introduced in 2014.

The security flaw, formally tracked as CVE-2026-110264, has been assigned a CVSS score of 10.0, representing the highest possible rating for severity. According to the company’s advisory, the vulnerability stems from an integer overflow that occurs during the compilation of a specially crafted regular expression. Under certain conditions, this flaw enables an unauthenticated attacker to execute arbitrary code directly on the underlying server without requiring any prior authentication or valid credentials.

While GitLab has not yet disclosed the precise preconditions required for an attacker to successfully reach the vulnerable compiler, the company reported that there is currently no indication that the flaw has been actively exploited in the wild. As of October 22, the vulnerability has not been added to the U.S. Cybersecurity and Infrastructure Security Agency catalog of known exploited vulnerabilities. Nevertheless, because the exact trigger conditions remain unpublished and no interim workarounds or configuration mitigations have been offered, administrators cannot rule out exposure through configuration alone, making immediate patching the only definitive protection.

The scope of affected deployments is strictly limited to self-managed installations. Hosted environments such as GitLab.com are already running the patched software, and GitLab Dedicated tenants utilizing internal releases 19.3.5-internal0, 19.4.2-internal0, or later have already received the necessary remediation. For self-managed instances, however, the emergency patch release requires urgent administrative attention, particularly given that many administrators may have believed their servers were already secured following a previous round of updates earlier in the month.

The discovery introduces a compounding challenge for IT and security teams who applied patches just days prior. On October 12, GitLab released an update covering versions 19.2 and later to address a separate regex-related flaw. Because the new October 21 patches sit one version above those previous fixes, any instance that was updated during the October 12 cycle is now immediately brought back into the deployment range and requires another upgrade.

In an unusual move for the software provider, GitLab backported the security fix across seven distinct release branches simultaneously, reaching four versions older than the company’s standard support policy normally dictates. Under its established lifecycle policies, GitLab typically limits ongoing maintenance patches to the current monthly release and the previous two monthly iterations, which currently encompass branches 19.5, 19.4, and 19.3. However, given the extreme severity and deep architectural roots of the vulnerability, the company expanded its backporting efforts to cover versions 19.2, 19.1, 19.0, and the long-standing 18.11 branch.

To resolve the vulnerability completely, administrators running affected systems must upgrade to the appropriate remediation version corresponding to their current deployment branch. Installations on branch 19.5 must move to version 19.5.1, while those on 19.4 need to update to 19.4.3. Systems operating on branch 19.3 require version 19.3.6, and those on branch 19.2 must upgrade to 19.2.9. For slightly older environments, administrators running branch 19.1 are advised to patch to version 19.1.9, while those on branch 19.0 must transition to version 19.0.10. Finally, any self-managed instance running legacy versions spanning from 7.0 through 18.11 must be upgraded to version 18.11.13.

The reason the vulnerability traces back through a decade of software releases lies deep within the architecture of GitLab’s codebase. The component responsible for the failure is the built-in regular expression engine of the Ruby language, known as Onigmo. GitLab packages this engine directly within its own software distributions and applies custom patches within its proprietary builds. Consequently, any underlying weakness residing within that specific compilation engine is inherently present across every single release where GitLab has shipped it over the past twelve years.

To assist security teams and system administrators in monitoring their environments for potential compromise or reconnaissance activity, GitLab has published two specific detection rules titled "Onigmo native worker crash" and "Org mode render error burst." These detection mechanisms are delivered as part of the company’s open-source TLDR framework, which expresses threat detection signatures in the Sigma format designed to evaluate application logs generated natively by GitLab.

The discovery of CVE-2026-110264 is part of a broader, highly concentrated cluster of vulnerabilities uncovered in GitLab’s regular-expression engine by an independent security researcher operating under the online handle joaxcar. Over the span of just one month, this researcher has identified four distinct code-execution flaws within the same underlying subsystem.

The preceding discoveries began on September 23, when GitLab patched two vulnerabilities designated as CVE-2026-93577 and CVE-2026-89078, both carrying a CVSS severity score of 9.9 but requiring an authenticated user account to exploit. Shortly after, on October 12, GitLab released fixes for CVE-2026-97229, another unauthenticated integer overflow in the regex compiler rated at the maximum CVSS score of 10.0, which affected branches 19.2, 19.3, and 19.4. While those earlier three flaws were limited to modern versions starting from branch 19.2, the latest October 21 vulnerability uniquely extends its reach deep into legacy installations dating back to 2014.

Alongside the critical regex-related flaw, the October 21 security advisory addresses ten additional vulnerabilities of high, medium, and low severity. Among these secondary issues are two security concerns focused on authentication and access control. The first, tracked as CVE-2026-15723 and rated high with a CVSS score of 8.2, could potentially allow an authenticated user to hijack another user’s account, though this scenario is restricted to specific configurations where an administrator has explicitly enabled both SAML and LDAP auto-linking features simultaneously.

The second notable secondary vulnerability, designated as CVE-2026-112212 with a high CVSS rating of 7.5, involves a cache-poisoning flaw located within GitLab’s OAuth and OpenID Connect authentication endpoints. Under network setups that rely on a shared caching infrastructure, this weakness could allow an attacker to redirect targeted sign-in and authentication flows toward a malicious external server under their administrative control.

Planning for the required upgrades involves important operational considerations for systems administrators, particularly regarding server availability. Specific updates, such as the 19.4.3 and 19.3.6 releases, incorporate mandatory database schema migrations that execute automatically during the upgrade process. For single-node server deployments, executing these database changes necessitates brief scheduled downtime while the migration scripts complete. Conversely, GitLab notes that multi-node distributed setups can apply the security patches without incurring downtime by adhering to the platform’s established zero-downtime upgrade procedures.