
GitLab's Second CVSS 10.0 in Nine Days Hits Every Version Since 7.0
GitLab shipped a security update on October 21 fixing CVE-2026-110264, an integer overflow in Ruby's built-in Onigmo regular-expression engine, which GitLab bundles into its own packages and patches in its own builds. The advisory says the flaw could, "under certain conditions," let an unauthenticated user run arbitrary code on the server; GitLab has not said what those conditions are. It carries a CVSS score of 10.0, the maximum. This is the fourth code-execution flaw in the regex engine reported by researcher joaxcar (via HackerOne) in about a month, and the first to reach versions before 19.2. The October 21 release fixes 11 security issues in all, one critical and the rest high, medium, or low.
The integer overflow (CWE-190) fires while compiling a specially crafted regular expression, corrupts memory, and leads to code execution on the server. Because GitLab builds and ships its own copy of the Onigmo engine, the weakness exists in every release it has shipped since version 7.0, released in 2014 — roughly 12 years of distributions. GitLab.com already runs the fixed version and needs no customer action; Dedicated tenants on internal builds 19.3.5-internal0 and 19.4.2-internal0 or later are covered as well. Every other self-managed Community and Enterprise Edition instance is in range. The advisory offers no interim workaround.
The October 12 fix for CVE-2026-97229 covered only the 19.2, 19.3, and 19.4 branches (19.2.8, 19.3.5, 19.4.2). The new flaw's fixed versions sit one patch above those: 19.5.1, 19.4.3, 19.3.6, 19.2.9, plus exceptional backports to 19.1.9, 19.0.10, and 18.11.13 — a break from GitLab's normal policy of patching only the current release and the previous two monthly releases. In other words, instances upgraded under the October 12 guidance are vulnerable again and need another round. The mapping: 19.5 to 19.5.1, 19.4 to 19.4.3, 19.3 to 19.3.6, 19.2 to 19.2.9, 19.1 to 19.1.9, 19.0 to 19.0.10, and 7.0 through 18.11 to 18.11.13.
joaxcar's streak against GitLab's regex engine continues. On September 23 he reported CVE-2026-89078 (a double-free) and CVE-2026-93577 (an integer overflow), both rated 9.9 and requiring a logged-in account. The October 12 CVE-2026-97229 was the first to reach 10.0 and drop the authentication requirement, affecting branches 19.2 through 19.4; Rapid7 reproduced it within 24 hours and published proof-of-concept code, Censys counted roughly 25,766 internet-facing hosts and 79,224 web properties running affected versions, and its 30-day EPSS exploitation probability stands at 0.5%, with no confirmed in-the-wild exploitation so far. September 10's CVE-2026-85706, a path traversal in the commits API also rated 10.0, has already entered CISA's Known Exploited Vulnerabilities catalog; CrowdSec reports that branches 18.7 through 18.10 will never receive a fix for it.
GitLab.com is already patched and Dedicated customers need no action. GitLab published two detection rules, "Onigmo native worker crash" and "Org mode render error burst," inside its open-source TLDR framework in Sigma format, to help administrators hunt exploitation attempts in application logs. Since the vendor has not disclosed the preconditions an attacker needs to reach the compiler, no configuration can be assumed to rule you out — upgrading is the only certain protection.
Administrators should inventory instances immediately and upgrade to the fixed release on their branch or later, prioritizing internet-facing servers; rotate CI variables and runner tokens afterward, and watch for anomalous regex submissions and worker crash logs. GitLab reports no sign the flaw has been used in attacks and it is not listed in the CISA catalog. But the lesson of the previous round stands: the public PoC for CVE-2026-97229 appeared within 24 hours of its patch, and maximum-severity GitLab flaws do not stay theoretical for long.