GitLab CVE-2026-97229 is now exploited: why patching GitLab alone may not close the hole

On 29 October, CISA added a maximum-severity GitLab vulnerability to its Known Exploited Vulnerabilities (KEV) catalogue, confirming that CVE-2026-97229 is being used in real attacks. The most useful detail in the story, though, comes from a victim. Alpine Linux, which hosts the build recipes for its packages on GitLab, patched to what it thought was a safe version and was still vulnerable. If you run your own GitLab, that lesson matters as much as the CVE itself.

What happened

GitLab disclosed and fixed CVE-2026-97229 on 12 October. Its advisory rates the flaw 10.0 on the CVSS 3.1 scale. It is an integer overflow in the regular expression compiler used when GitLab processes CI/CD configuration files. Under certain conditions, an unauthenticated attacker could run arbitrary code on the server using a specially crafted regular expression. The researcher "joaxcar" reported it through HackerOne.

GitLab's advisory lists the affected versions as 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. GitLab.com and GitLab Dedicated were already patched, so the exposure is for self-managed installations. The advisory offers no workaround and recommends upgrading as soon as possible.

Exploitation followed quickly. According to Alpine's own incident write-up, a newly registered account sent crafted CI configurations to its GitLab server on 20 and 21 October, about a week after the fix was published. On 29 October CISA added the CVE to KEV. SecurityWeek reports a three-day deadline for US federal agencies under BOD 26-04. BleepingComputer adds that Shadowserver tracks nearly 2,800 internet-exposed GitLab Community Edition instances, though it does not say how many are patched.

The Alpine near miss

Alpine's account is candid and worth reading in full. The attacks crashed GitLab worker processes eight times. In four of those, the attacker got partway through the exploit before failing at the next stage. The attacker also downloaded Alpine's GitLab container image, which Alpine reads as an attempt to tune the exploit to its build.

Alpine found no evidence that code ran on the server, no tampering with its package build recipes, packages or releases, and says its signing keys were never stored on the GitLab server. It could not rule out compromise, however, because some logs were missing and it had no record of outbound connections. It rebuilt the instance from scratch and reset all passwords and GitLab secret keys.

The timeline explains why it was exposed:

• 13 October: Alpine upgraded to 19.3.4, not the fixed 19.3.5, which Alpine calls a mistake.
• 22 October: It upgraded to 19.3.6, which did not close the hole in its setup.
• 26 October: Alpine found the instance was still vulnerable.

The root cause sits in Onigmo, the regular expression engine built into Ruby. As Alpine and The Hacker News describe it, GitLab's fix works by patching the Ruby shipped in its own official Linux packages and container images. Upstream Ruby fixes arrived on 22 and 23 October, in versions 3.3.13, 3.4.12 and 4.0.9. An installation built around a different Ruby does not pick up the fix just by installing a newer GitLab version.

Why it matters

• Version numbers can mislead. A patched application version is not proof of a patched dependency. This is the same pattern we see whenever critical code is bundled, vendored or built into custom images.
• The impact would have been severe. Alpine lists what a successful attacker could reach on a GitLab server: password hashes, 2FA secrets, CI/CD variables, runner tokens, webhook and mirror credentials, and private repositories. A source-control host is a stepping stone into software supply chains.
• The gap was a week. Exploitation began roughly eight days after the vendor fix and before the KEV listing. Waiting for the KEV listing before acting would have been too late.
• Logging decided how certain Alpine could be. With 14-day log retention and no outbound connection records, a clean result could not be proven.

Implications for organisations

If you run self-managed GitLab, treat this as an incident-readiness test rather than a routine patch:

1. Upgrade now to 19.2.8, 19.3.5, 19.4.2 or later, noting that the patch includes database migrations and a single-node instance will have downtime.
2. Verify the Ruby. If you build GitLab from source or use a custom image, confirm it runs Ruby 3.3.13, 3.4.12, 4.0.9 or later. Ruby 3.2 reached end of life in April and will not receive a fix, according to The Hacker News.
3. Use GitLab's six published threat detections for self-managed instances, and look for unexplained worker crashes, 502 errors, failed CI jobs and recently registered accounts submitting pipeline configurations.
4. Restrict who can register and who can run pipelines on instances reachable from the internet, and place them behind a VPN or access proxy where practical.
5. If you were exposed after 12 October, assume secrets may be at risk. Rotating CI/CD variables, runner tokens and integration credentials is cheap compared with proving they were never read.
6. Extend log retention and capture outbound connections from build and source-control hosts.

What to watch next

Watch whether GitLab or CISA publish more detail on the exploitation seen beyond Alpine, and whether further self-managed breaches are disclosed. Also watch for downstream container and distribution images that bundle older Ruby builds. This is also the second maximum-severity GitLab regular expression compiler flaw this month, according to BleepingComputer, which is a signal worth noting for anyone who treats GitLab as low-risk internal tooling.

Pholarix perspective

This is our interpretation rather than reported fact. The incident is a useful reminder that "we upgraded" and "we are fixed" are separate claims, and the difference is greatest where software is assembled from parts. The practical control is to verify the outcome, not the version number, by checking the bundled runtime, testing the detections and holding enough logs to answer the question afterwards. It is also another case for treating source-control and CI systems as part of the internet edge, with a named owner and a fast patching lane, as we argued in our pieces on exposed edge systems and patching at scale.

If you would like an independent view of your exposure, our free Aegis assessment is a good place to start.

Sources: BleepingComputer, "CISA says max severity GitLab flaw now exploited in the wild"; BleepingComputer, "Alpine Linux rebuilds GitLab after attempted RCE attack"; SecurityWeek, "Max-Severity GitLab Vulnerability Exploited Against Alpine Linux"; The Hacker News, Alpine Linux GitLab exploit attempt; Alpine Linux, "GitLab security incident: CVE-2026-97229"; GitLab, patch release 19.4.2 advisory.