GitLab ships second maximum severity patch in ten days for unauthenticated flaw

GitLab's self-managed customers have spent October 2026 in a patch cycle that keeps widening rather than closing. On October 21, 2026, the company shipped new security releases for Community Edition and Enterprise Edition, and the headline item is a maximum severity vulnerability that an unauthenticated attacker could use to run code on a GitLab server. The flaw is tracked as CVE-2026-110264 and sits in the regular expression compiler, a component most administrators never think about until it becomes the shortest path to remote code execution.

The timing is part of the story. The October 21 release came ten days after GitLab's October 12 update for CVE-2026-97229, another maximum severity regex flaw, and it is the fourth code execution flaw in that regex engine reported by the same HackerOne researcher in a month. The Hacker News reported on October 22, 2026 that the new flaw affects every version of GitLab going back to 7.0, which was released in 2014. That reach means administrators who patched nine days earlier are in range again, because the October 12 update covered only versions 19.2 and later and the new fixed versions sit one patch above it.

GitLab's official advisory frames the issue in careful language. GitLab Docs reported on October 21, 2026 that CVE-2026-110264 is an integer overflow in the Regular Expression Compiler and that, under certain conditions, it could have allowed an unauthenticated user to execute arbitrary code on the GitLab server when compiling a specially crafted regular expression. The advisory does not spell out those conditions, and it offers no workaround. That combination, a maximum score and an unknown trigger, is why the release has drawn attention from security teams far beyond GitLab's own customer base.

Key Facts

The fixed releases are 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 Edition and Enterprise Edition. GitLab Docs reported on October 21, 2026 that the company strongly recommends all self-managed installations upgrade immediately. GitLab.com already runs the patched version, and GitLab Dedicated tenants on 19.3.5-internal0 and 19.4.2-internal0 or later already include the fixes. Only self-managed installations need to act.

The vulnerability has a CVSS score of 10.0, with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The impacted versions are all GitLab CE and EE releases from 7.0 before 18.11.13, 19.0 before 19.0.10, 19.1 before 19.1.9, 19.2 before 19.2.9, 19.3 before 19.3.6, 19.4 before 19.4.3, and 19.5 before 19.5.1. The range is unusually wide, and it explains why the patch list includes seven versions rather than the usual three.

GitLab also went beyond its standard support policy. Its normal policy covers only the current release and the two previous monthly releases, which would be 19.5, 19.4 and 19.3. GitLab Docs reported on October 21, 2026 that it backported the fix to 18.11.13, 19.0.10, 19.1.9 and 19.2.9, a step it normally reserves for severe issues. The Hacker News reported on October 22, 2026 that four of the seven fixed versions are older than that normal patching window.

The same release fixes 11 security issues in total. GitLab Docs reported on October 21, 2026 that the batch includes high severity CVE-2026-15723, an improper authentication flaw in OmniAuth to LDAP auto-linking email lookup with a CVSS score of 8.2, and CVE-2026-112212, a cache poisoning flaw in OAuth and OIDC discovery endpoints with a CVSS score of 7.5. CERT-EU reported on October 22, 2026 that the release contained 2 high severity, 5 medium severity and 4 low severity vulnerabilities in addition to the maximum severity issue.

GitLab credited the researcher using the HackerOne handle 'joaxcar' and published two detection rules through its open source TLDR framework. The rules are named 'Onigmo native worker crash' and 'Org mode render error burst', and they are intended to help administrators hunt for exploitation attempts in GitLab logs. GitLab Docs reported on October 21, 2026 that the bulletin offers no workaround and that vulnerability details become public 90 days after the patch. The Hacker News reported on October 22, 2026 that GitLab has no sign the flaw has been used in attacks and that the CVE is not listed in CISA's Known Exploited Vulnerabilities catalog as of that date.

Analysis

The most important technical detail is where the flaw lives. The Hacker News reported on October 22, 2026 that the root cause is Ruby's built-in regular expression engine, Onigmo, which GitLab ships inside its own packages and patches in its own builds. Because GitLab has shipped that engine in every release since 7.0, the weakness is present wherever GitLab has shipped the engine. This is not a case of a single feature toggle or a misconfigured option. It is a dependency that travels with the product.

That dependency view changes how security teams should read the patch. InfoWorld reported on October 22, 2026 that Noah Kenney, principal consultant at Digital 520, said what stands out is that the issue originates in an integer overflow within the regular expression compiler rather than functionality GitLab developed. Kenney highlighted dependency risk: organizations can invest heavily in securing their own applications while remaining exposed through underlying libraries. He also said the fact that the flaw affects releases dating back to GitLab 7.0 shows how long such vulnerabilities persist. That is a fair reading of the evidence, and it puts the onus on asset inventory as much as on code review.

What this really means is that the most serious risk in a modern DevSecOps platform can come from a component the platform vendor ships and patches on its own schedule, not from the feature code that customers review and test. GitLab can fix its own authentication flow, its own OAuth endpoints and its own cache logic, and still inherit a maximum severity bug from the regex engine underneath. The October 21 release is therefore less a story about one bad line of GitLab code and more a story about the supply chain that sits inside a single binary distribution.

The patch cadence adds operational risk. InfoWorld reported on October 22, 2026 that the update forces database migrations and downtime, which matters for teams that run GitLab as a critical internal service. The October 12 update did not cover versions before 19.2, so an administrator who patched then is not finished. The new fixed versions sit one patch above the October 12 release, which means a second maintenance window in ten days. GitLab also fixed a line buried in the bug fixes, not the CVE list, about stripping the trusted flag from client supplied MCP tools in Workhorse. Kenney said that in plain terms this means GitLab found a path where an AI agent could be handed tools it should not have trusted.

Why It Matters

CERT-EU treated the issue as urgent for European enterprises. CERT-EU reported on October 22, 2026 that it published Security Advisory 2026-019 at 09:14, one day after GitLab's disclosure. The advisory states that the critical flaw could allow an unauthenticated user to execute arbitrary code on a GitLab server and recommends that organizations update affected assets as soon as possible, prioritizing internet facing assets, and run an assessment to identify compromised assets. It also frames the practical risk for European enterprises running self-managed DevSecOps infrastructure, where a single unpatched internet facing instance can expose source code, CI/CD pipelines and deployment credentials.

The exposure is not theoretical even without confirmed exploitation. A GitLab server is often the place where source code, build secrets, runner tokens and deployment credentials meet. An unauthenticated remote code execution flaw in that system is a direct path to the software supply chain, and the CVSS vector reflects that: network access, low attack complexity, no privileges required, no user interaction, and high impact on confidentiality, integrity and availability. GitLab's own score of 10.0 is the maximum, and the company's advisory says the flaw could have allowed arbitrary code execution, not merely data disclosure.

The absence of a CISA KEV listing is not a reason to wait. The Hacker News reported on October 22, 2026 that GitLab reports no sign of exploitation and that the CVE is not in CISA's Known Exploited Vulnerabilities catalog as of that date. That status can change, and it does not reduce the value of patching an internet facing instance that holds credentials. CERT-EU's recommendation to run a compromise assessment is the right complement to upgrading, because a patch closes the door but does not tell an organization whether someone already walked through it.

Next Up

The immediate next step for self-managed administrators is to move to one of the fixed versions and to treat the October 12 patch as incomplete. GitLab Docs reported on October 21, 2026 that the company strongly recommends upgrading immediately and offers no workaround. Organizations should prioritize internet facing instances, then internal instances that hold CI/CD credentials, and should retain logs long enough to use the two published detection rules.

The next checkpoint is disclosure. GitLab says vulnerability details become public 90 days after the patch, so the window for quiet remediation is limited. CERT-EU's call for a compromise assessment and the Hacker News note that the CVE is not yet in CISA's Known Exploited Vulnerabilities catalog give administrators two different signals to watch: a technical signal from their own logs and a public signal from CISA. Both should be checked before the 90 day mark.