GitLab regex flaw since 2014

GitLab released fixes on October 21 for a flaw that lets an unauthenticated attacker run arbitrary code on a self-managed server, and it affects every version of the software going back to 7.0, which shipped in 2014. The bug, CVE-2026-110264, is rated 10.0 on CVSS, the maximum.

The reason it reaches so far back is which component failed. GitLab compiles regular expressions with Ruby’s built-in engine, Onigmo, which it ships inside its own packages and patches in its own builds. The flaw is an integer overflow during the compilation of a specially crafted regular expression, and because that engine has been present in every release since 7.0, so has the weakness. GitLab has not said what conditions an attacker needs to reach the compiler, so you cannot rule your instance out by configuration. The advisory offers no interim workaround. Applying the fix is the only certain protection.

Only self-managed installations need to act. GitLab.com already runs the fixed version, and GitLab Dedicated tenants on internal releases 19.3.5-internal0 and 19.4.2-internal0 or later already have it. GitLab reports no sign of exploitation, and as of October 22 the CVE is not in CISA’s known-exploited catalog.

Patching nine days ago is not enough

If you updated on October 12, you are back in range. That update fixed CVE-2026-97229, another unauthenticated 10.0 overflow in the same regex compiler, in versions 19.2.8, 19.3.5, and 19.4.2. It covered only 19.2 and later, and the October 21 fixed versions sit one patch above those, so an instance updated on the 12th is vulnerable again.

That makes the fleet inventory the hard part of this one. GitLab fixed the flaw in seven versions at once. Its support policy covers the current release and the previous two monthly releases, which today are 19.5, 19.4, and 19.3. Four of the fixed versions sit below that line: GitLab backported the fix to 18.11.13, 19.0.10, 19.1.9, and 19.2.9, a step it reserves for severe issues. So an audit that only checks whether supported branches are current will miss older instances that are also affected. Map every running version to its fixed version before you start scheduling upgrades.

Detection and the upgrade cost

GitLab published two detection rules for self-managed administrators to look for exploitation attempts, named “Onigmo native worker crash” and “Org mode render error burst.” Both are part of its open-source TLDR framework and are written in Sigma format against GitLab’s own application logs.

The upgrade itself carries downtime on smaller deployments. The 19.4.3 and 19.3.6 releases include database changes that run during the upgrade, and on a single-node server that means the instance is down while the migrations finish. Multi-node setups can apply the patch without downtime using GitLab’s zero-downtime procedure. Plan the maintenance window accordingly, because for most teams this server is the thing everyone else’s work depends on.

One in a run of four

This is the fourth code-execution flaw in GitLab’s regex engine reported by the researcher using the handle joaxcar in a month, and the first to reach versions before 19.2. The September 23 fixes, CVE-2026-93577 and CVE-2026-89078, were both rated 9.9 but required a logged-in account. The three earlier flaws stopped at version 19.2; this one does not, which is why the backports go back as far as they do.

The October 21 release closes 11 security issues in total, one critical and the rest high, medium, or low. Two others concern authentication and are worth noting if your setup matches their preconditions. CVE-2026-15723 (high, 8.2) could let a logged-in user take over another account, but only when an administrator has enabled both SAML and LDAP auto-linking. CVE-2026-112212 (high, 7.5) is a cache-poisoning flaw in GitLab’s OAuth and OpenID Connect endpoints that could redirect certain sign-in flows to a server the attacker controls, in deployments that use a shared cache.