Attackers are already exploiting CVE-2026-97229, a critical vulnerability that can allow code execution on GitLab servers. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) confirmed active exploitation on October 29 and added the flaw to its Known Exploited Vulnerabilities catalog.
The issue lies in the regular expression compiler used to process CI/CD configurations. GitLab released fixes on October 12, but the Alpine Linux case shows that evidence of an attempted attack does not amount to confirmation of a breach: the organization found concerning signs in its instance, but could not determine whether the attacker managed to execute code.
What the flaw allows and which versions are patched
Identified as CVE-2026-97229, the flaw stems from an integer overflow in the CI/CD regular expression compiler. A specially crafted expression in a pipeline configuration can, under certain conditions, bypass validation and lead to arbitrary code execution on the server. GitLab described the issue as potentially allowing execution by an unauthenticated user.
Rapid7, which reproduced the vulnerability, specifies an important condition for this attack path: the attacker must be able to introduce a malicious CI/CD configuration into a repository before triggering the flaw. On a self-managed instance that allows new users to register and create public projects, this may be possible with an ordinary account. Rapid7 confirmed the exploit chain on the official GitLab CE 19.4.1 image and says the same input did not execute code on the patched 19.4.2 image.
GitLab released versions 19.4.2, 19.3.5 and 19.2.8 for Community Edition and Enterprise Edition. These are the patched versions for their respective branches: self-managed installations running earlier versions within those branches should upgrade. GitLab.com has already been patched, and GitLab Dedicated customers do not need to take action, according to Rapid7 and GitLab documentation.
CISA ordered U.S. federal agencies to secure their servers by Sunday under directive BOD 26-04. Although that deadline applies to federal agencies, the agency also recommended that private-sector teams prioritize upgrading. GitLab also published threat detections for customers with self-managed instances.
Alpine detected attempts and rebuilt its instance
Alpine Linux reported that an attacker tested the vulnerability against its GitLab server on October 20 and 21, after GitLab had released the patch. Alpine's instance was still running GitLab 19.3.4. According to its analysis, a newly registered account submitted manipulated CI/CD configurations that caused eight worker process crashes; in four of them, the attacker made partial progress with the exploit but did not complete the next step.
The attacker also downloaded Alpine's GitLab container image, suggesting they may have been tuning the exploit for that specific build. Alpine said it found no evidence that code had been executed, but could not rule it out. Because the available logs could not eliminate that possibility, it treated the server as compromised and rebuilt it from scratch.
The organization verified that the aports repository, packages, and October 21 releases had not been altered. It also noted that package and release signing keys were not stored on the GitLab server. Its instance reopened on October 29 with GitLab 19.3.7, following the shutdown and rebuild.
The incident revealed another technical nuance: Alpine explained that upgrading GitLab alone was not sufficient in its case. The fix also depends on a Ruby patch included by GitLab in its official packages; Alpine's image used a standard version of Ruby that did not include it. The organization said that those deploying GitLab with their own Ruby should also upgrade Ruby to a patched version: 3.3.13, 3.4.12 or 4.0.9, or later.
During the shutdown, Alpine reset passwords and replaced GitLab secret keys. It also announced that it would apply critical GitLab patches within one day, check whether each release requires Ruby or other component upgrades, and expand logging of outbound and database connections. For self-managed instances that cannot yet upgrade, Rapid7 mentions temporary measures such as restricting anonymous access to public projects and preventing untrusted users from creating or modifying public projects; these measures reduce exposure to the demonstrated attack path but do not fix the vulnerable compiler.
Sources: BleepingComputer, Rapid7, Alpine Linux, GitLab Docs
