GitLab shipped the patch on 12 October. Three weeks later the exploit is live, the US cyber agency has given federal agencies a deadline, and Shadowserver's scan of the public internet still finds more than a thousand self-managed GitLab servers that never installed it.

The flaw is CVE-2026-97229, and it carries a CVSS score of 10.0 — the maximum. It is an integer overflow in GitLab's CI/CD Regular Expression Compiler, the component that parses, compiles and evaluates the regexes teams write into pipeline configuration. The compiler did not validate its input well enough, and an attacker who supplies a crafted pattern reaches arbitrary code execution on the server without authenticating at all.

That last detail is what makes it a 10.0 rather than a bad week. GitLab's own advisory describes an unauthenticated user executing arbitrary code "via a specially crafted regular expression in a CI/CD configuration". No credential, no runner token, no repository write access — the pipeline definition itself is the attack surface. The overflow is reported to sit in Onigmo, the regular-expression engine bundled with Ruby, which GitLab uses to compile those patterns; an integer that wraps during compilation becomes memory corruption, and memory corruption in the process holding every repository, CI variable and deployment secret on the instance is as bad as it sounds.

The timeline is short. GitLab published fixed releases — 19.4.2, 19.3.5 and 19.2.8 for Community and Enterprise Edition — on 12 October. GitLab.com was already patched, and GitLab Dedicated customers needed to do nothing. On Friday, CISA confirmed in-the-wild exploitation, added the CVE to its Known Exploited Vulnerabilities catalogue, and ordered US federal agencies to remediate by Sunday under Binding Operational Directive 26-04.

Then Shadowserver published what the internet actually looks like. On Sunday the non-profit's scanning project reported more than 1,000 internet-exposed GitLab instances still vulnerable to CVE-2026-97229 — and, in the same update, more than 11,300 vulnerable to CVE-2026-110264, a maximum-severity RCE in the same regex compiler that GitLab had fixed a month earlier. The denominator is roughly 39,000 GitLab instances Shadowserver sees daily. German outlet Golem.de led with the larger figure: around 11,000 attackable GitLab instances on the net.

Two ten-out-of-ten bugs in one component within a month is not bad luck; it is a design signal. A regex compiler is a parser with a long history of memory-safety trouble, and GitLab placed it in the path of unauthenticated configuration input. Whether the second bug is a variant of the first or an independent mistake, the lesson is the same: the CI/CD control plane is now a perimeter, and it is being scanned like one.

This is the sixth GitLab flaw CISA has added to the KEV catalogue since November 2021, one of which was used in ransomware operations. 2026 alone has produced a two-factor bypass (CVE-2026-0723, January), a path traversal in the repository commits API rated 10.0 (CVE-2026-85706, September, also exploited), and now two regex-compiler RCEs. The pattern points at the prize: a GitLab server is where source code, pipeline secrets, cloud keys and deployment rights all meet. Compromise one and you inherit the build pipeline — the classic route to poisoning everything downstream.

There is no public report yet of a named victim or a confirmed supply-chain compromise from this campaign. That gap matters: exploitation is confirmed, scope is not. Shadowserver's count is a census of exposure, not of breaches.

What to do:

- Check the version. Anything below 19.4.2, 19.3.5 or 19.2.8 — or the equivalent patch level on a later release line — is in scope for the first bug; the second was fixed earlier and is the reason the 11,300 figure exists. - If an instance sat on the public internet unpatched, treat CI variables, runner tokens, deploy keys and registry credentials as potentially exposed and rotate them. Patching closes the door; it does not undo a visit. - Look for pipeline runs triggered by unfamiliar accounts or from forks whose configuration carries unusual regex-heavy patterns, and for outbound connections from the GitLab host that do not belong there. - If patching cannot happen this week, take the instance off the public internet. Every exploit in this class starts with a request that only a reachable server ever sees.

The honest summary: a patch has existed for three weeks, an external scanner can find the unpatched from outside, and exploit code is in circulation. This is the rare critical that is entirely preventable — and still isn't being prevented.

Sources