GitLab's 10.0 RCE: 25,766 Self-Managed Servers Still Unpatched After Sunday's Emergency Fix

On Sunday, October 12, 2026, GitLab shipped emergency releases across three supported branches, 19.2.8, 19.3.5, and 19.4.2, to close a flaw that scores the maximum 10.0 on the CVSS scale. The bug, now cataloged as CVE-2026-97229, lives inside the platform's CI/CD regular expression compiler. An integer overflow combined with weak input checks lets a crafted regular expression inside a .gitlab-ci.yml file trigger arbitrary code execution on the server itself. Within 24 hours, Rapid7 had published a working proof of concept. A day after that, Censys was counting the exposed fleet that had not patched: 25,766 hosts, reachable and vulnerable, as of October 13.

This is a self-hosted story in its purest form. GitLab.com, the hosted version, already runs the corrected code, and GitLab Dedicated customers needed to do nothing. The vulnerable population is the self-managed fleet: organizations and individuals running GitLab on their own infrastructure, the same sovereignty-first crowd that keeps its source code, build pipelines, and secrets on hardware it controls. The sovereignty argument works until the patch cycle slows down. The people who update the least absorb the largest share of the risk, and this week the numbers say that group is large.

A regex compiler at the heart of the software factory

The technical detail is what makes this one hurt. The bug is not in some obscure plugin. It sits in the CI/CD regular expression compiler, the component that parses the patterns developers use to gate jobs, match branches, and filter variables. An attacker who can commit a crafted .gitlab-ci.yml file to a public project's branch, with a repository path containing UTF-8 characters, can force the integer overflow and get code execution inside a GitLab application worker running with the privileges of the git system user. From there, the paths open to source code, CI/CD secrets, runner tokens, and downstream deployment targets.

GitLab's original advisory described the flaw as reachable by an unauthenticated user under certain conditions, and Rapid7's analysis added the nuance. On instances that allow open registration, an adversary can simply create an account and the necessary public project, which is why self-hosters who left the front door open should be the most worried. The vulnerability was reported by a researcher operating under the handle joaxcar through the HackerOne bug bounty program, and the same Rapid7 write-up notes that the attack code evades some repeat scanners and US-ASCII size checks by hiding an inline comment inside a quantifier. Forensic artifacts from an attack in progress may be genuinely subtle.

The exposure numbers are sobering

Censys scanned the internet and found 25,766 exposed hosts still running vulnerable versions as of October 13, the day after the patch landed. Another 79,224 web properties tie back to those instances. Roughly 31 percent of all detected GitLab hosts remained unpatched. Germany leads with 6,469 vulnerable systems, Russia follows at 4,173, and the United States shows 2,927. Censys published the breakdown alongside its advisory.

The pattern will be familiar to regular readers of this section. Weeks ago, a Censys scan found 114,000 exposed n8n instances, a different self-hosted boom with a similar bill coming due. The dynamic repeats because the incentives repeat: self-hosting is growing faster than patching discipline, and internet-facing instances accumulate like shipping containers at a port. Publicly reachable GitLab instances without strict project creation controls sit in the crosshairs, and the proof of concept reached the public within 24 hours of the patch. That shrinks the comfortable window between disclosure and exploitation from weeks to days.

When the software factory can be taken over without credentials, the blast radius stretches across every repository, secret, and production deployment it touches.

One critical, three highs, zero comfortable excuses

The October 12 releases did not carry a single fix. The same patch bundle closed three high-severity issues alongside the critical one: an 8.7 stored XSS delivered through crafted repositories, an 8.5 authorization bypass allowing developers to trigger pipelines on protected branches, and an 8.2 cache-poisoning bug that could expose protected environment variables through specially crafted raw file requests. A release note like that is a reminder that the CI/CD surface keeps growing: more AI features, more downstream pipelines, more memory-safety and validation gaps in areas that were once quiet. Only weeks earlier, GitLab had fixed other integer overflow and double-free bugs in the same regex parsing area, which suggests this code path deserves sustained auditing, not a single patch.

Security leadership reacted with unusually direct language. Shane Barney, chief information security officer at Keeper Security, told SC Media that a 10.0 remote code execution inside the CI/CD compiler demands immediate action, arguing that the compiler sits at the trusted heart of the build system. Rapid7 recommended upgrading outside normal patch windows precisely because the flaw executes in the application worker itself. GitLab's own statement stayed measured, framing the fix as remediation of an issue that could have let an unauthenticated user execute arbitrary code via a specially crafted regular expression due to insufficient validation. Measured or not, the data on exposure and the working exploit leave operators one question: has the instance been updated?

What self-managers should do right now

Upgrade first, and do not wait for the monthly window. If your instance was internet-facing at any point between early October and the deployment of these fixes, treat it as potentially compromised rather than merely vulnerable. That means rotating CI/CD secrets, deploy keys, and personal access tokens, plus any credentials stored in affected environment variables. Review pipeline logs, runner activity, and unexpected processes spawned from the git user. Look for commits that introduced unusual regex patterns or repository paths with non-ASCII characters.

Then fix the structural problems this incident exposed. If your instance allows open registration, decide whether it should. If the management interface is reachable from the public internet, ask whether it needs to be. Security teams that maintain GitLab at scale already schedule monthly upgrades; this one could not wait, and the next one like it will arrive with a public PoC and a Censys dashboard on the same timeline. The fix exists, the exposure data exists, the working exploit exists. The sovereignty dividend of running your own infrastructure is real, but it is paid for in operational discipline, and this week sent the invoice.

References

• WebProNews, "GitLab's CVSS 10.0 RCE Exposes Self-Managed Servers as PoC Surfaces," webpronews.com, October 2026
• Rapid7 security analysis of CVE-2026-97229, referenced via the coverage above, October 2026
• Censys internet scan data on exposed GitLab hosts, October 13, 2026