AI News
GitLab Patches CVSS 10.0 Unauthenticated RCE Affecting Versions Back to 2014
On October 21, GitLab shipped a critical patch for CVE-2026-110264, a vulnerability scored CVSS 10.0 — the maximum possible — that lets an unauthenticated user execute arbitrary code on a self-managed GitLab server. The flaw is an integer overflow in GitLab's regular expression compiler, triggered when the server compiles a specially crafted regular expression. GitLab credited researcher Johan "joaxcar" Carlsson, who reported it through the company's HackerOne bug bounty program. The striking detail is the affected range: every release back to version 7.0, from 2014. And this is the second maximum-severity flaw in the same component this month.
What the flaw does
GitLab's own wording is careful: under "certain conditions," the flaw "could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression." The CVSS vector explains the 10.0 score: network-accessible, low complexity, no privileges required, no user interaction, and scope-changed, with high impact on confidentiality, integrity and availability. GitLab has not published what the "certain conditions" are. Its detection notes, however, name one concrete path: a crafted Org-mode (.org) file in any public project, rendered by the server. The practical reading is that an attacker needs a way to get a malicious regular expression in front of the server's compiler — and on instances where anyone can self-register and create projects, that barrier largely disappears, as Rapid7 noted when analyzing the first flaw.
Why it matters beyond the score
Self-hosted GitLab servers are unusually rich targets. They typically hold proprietary source code, CI/CD secrets, access tokens and connections to production environments — the exact material needed for the next stage of an attack. Threat detection firm SOC Prime lists the plausible outcomes: credential theft, repository manipulation, supply chain attacks, persistence and lateral movement into the wider network. GitLab says more than half of the Fortune 100 use its platform. The patch strategy itself signals severity: beyond the standard releases, GitLab backported the fix to four branches it would normally have left behind — 18.11.13, 19.0.10, 19.1.9 and 19.2.9, alongside 19.3.6, 19.4.3 and 19.5.1. As one security analyst put it, GitLab almost never patches branches this old, and that alone says how serious this is.
The trap: the October 12 patch does not cover this
On October 12, GitLab patched CVE-2026-97229 — an integer overflow in the same CI/CD regex compiler, with the identical 10.0 vector, fixed in 19.2.8, 19.3.5 and 19.4.2. Rapid7 reproduced arbitrary code execution on an unpatched official GitLab image within a day, and a proof of concept circulated from October 13. Censys counted 25,766 hosts and 79,224 web properties running versions affected by that first flaw. Teams that rushed to apply the October 12 fix could reasonably believe they were done. They are not: those fixed versions sit below the new fixed versions, so they remain inside the affected range for CVE-2026-110264. If your instance shows 19.4.2, 19.3.5 or 19.2.8, you patched the first flaw — and you still need this one.
What to do
Upgrade every self-managed GitLab CE or EE instance to the fixed version for its release line, starting with internet-facing ones: 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 or 19.5.1. GitLab.com already runs the patched version, and GitLab Dedicated tenants on 19.3.5-internal0 or 19.4.2-internal0 and later need no action — the exposure is on self-managed installations. GitLab also released two threat detection tools to help uncover exploitation attempts, and the same patch release resolved eleven lower-severity issues, including a high-severity LDAP account takeover and an OAuth/OIDC cache poisoning flaw. Two facts should temper the urgency without removing it: GitLab has reported no in-the-wild exploitation of this flaw, and it is not in CISA's Known Exploited Vulnerabilities catalog. But the first flaw's history — public proof of concept within a day — is the reason to treat a maximum score with no confirmed exploitation as a short fuse, not a reprieve.
While the upgrade runs, check for signs of earlier compromise, because a flaw this visible attracts probing within hours of disclosure. Review recently created projects and pipeline runs, unexpected administrator accounts, and changes to CI/CD configuration files, and run the two threat detection tools GitLab released with the patch. An internet-facing instance that sat unpatched through the October 12 flaw, let alone this one, should be treated as potentially probed until that check comes back clean — patching closes the hole, but it does not undo anything that already passed through it.