A maximum-severity flaw in self-hosted GitLab is now confirmed as actively attacked, and the organisation that came closest to losing control of its server has published exactly what went wrong. The uncomfortable part is that the GitLab upgrade it applied did not actually close the hole.

What happened

CVE-2026-97229 is an integer overflow in the regular expression compiler GitLab uses to evaluate CI/CD pipeline configuration. GitLab scored it 10.0 and shipped fixes on 12 October in 19.2.8, 19.3.5 and 19.4.2. The underlying bug is not in GitLab's own code: it sits in Onigmo, the regular expression engine built into Ruby. GitLab's fix is a patch to the Ruby it bundles in its official packages and container images.

CISA added the CVE to its Known Exploited Vulnerabilities catalog on 29 October and gave US federal agencies until 1 November to patch.

The evidence behind that listing came from Alpine Linux. On 20 and 21 October a newly registered account sent crafted CI configurations to gitlab.alpinelinux.org, which was still running 19.3.4. GitLab worker processes crashed eight times and in four of those attempts the attacker got partway through the exploit and failed at the next step. The attacker also pulled Alpine's GitLab container image, which suggests the exploit was being tuned to that specific build. Alpine found no proof that code ran, but could not rule it out, so it rebuilt the instance from scratch, reset every password and replaced GitLab's secret keys.

Alpine had upgraded to 19.3.6 on 22 October and the instance was still vulnerable, because that image used standard Ruby rather than GitLab's patched packages. Ruby itself only shipped the fix on 23 October, in 3.3.13, 3.4.12 and 4.0.9.

Who is affected

• Self-managed GitLab CE and EE versions 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2.
• Any GitLab installed from source or run from a custom container image built on system Ruby, even on a newer GitLab release.
• Servers that allow self-registration or public project creation, because the exploit needs a malicious .gitlab-ci.yml committed to a public project.
• Other applications that compile regular expressions from untrusted input on an unpatched Ruby build.
• Not affected: GitLab.com and GitLab Dedicated customers, who are already on patched infrastructure.

What to do now

Get self-managed GitLab onto 19.2.8, 19.3.5 or 19.4.2 from GitLab's official packages or images, then confirm the Ruby underneath is 3.3.13, 3.4.12 or 4.0.9 and later.

• Check the exact version with gitlab-rake gitlab:env:info and compare it to the fixed releases; a version bump on a custom image is not proof of a fix.
• If you build your own image or run GitLab from source, apply the Ruby patch yourself. The GitLab release alone will not carry it.
• Disable self-registration and public project creation on internet-facing instances until the upgrade is verified.
• Treat any exposed GitLab as compromised until proven otherwise: look for crashed worker processes, 502 errors, unexpected accounts, new CI/CD variables, runners, deploy keys or access tokens.
• Rotate CI/CD variables, runner registration tokens, webhook and integration secrets, personal access tokens, and reset 2FA for administrators.

What this means for South African businesses

GitLab is not a mass-market product here, so this will hit a narrow set of South African organisations: software houses, engineering teams and any business that keeps its own code off cloud git hosting. Those instances are usually handed to a developer to look after and then forgotten, which is precisely the profile of a server that sits months behind on patches.

The risk is disproportionate to the install count. A self-hosted GitLab holds CI/CD variables, deploy keys and runner tokens for production and cloud environments, so a successful exploit hands an attacker the credentials to everything the pipeline can reach, not just source code. Our judgement is that the Ruby caveat is the real lesson: teams that rebuilt their own images will read "we are on the latest GitLab" and believe they are patched when they are not.

Source

The incident timeline, affected versions and Ruby requirements are documented in the Alpine Linux security incident notice.