Critical GitLab Flaw Exploited as Alpine Linux Rebuilds Its GitLab After Attack

A critical GitLab vulnerability that can let an attacker run code on a self-managed GitLab server is now being exploited, according to CISA. Alpine Linux, the popular Linux distribution, says an attacker tried to use the flaw against its own GitLab instance, which forced the project to shut it down, rebuild it and reset every user's password.

What happened

On October 12, 2026, GitLab released versions 19.4.2, 19.3.5 and 19.2.8 for GitLab Community Edition (CE) and Enterprise Edition (EE) to fix CVE-2026-97229, which it describes as an integer overflow in the CI/CD regular expression compiler. GitLab gives it the maximum CVSS score of 10.0 and says the bug "could have allowed an unauthenticated user to execute arbitrary code on the GitLab server via a specially crafted regular expression in a CI/CD configuration." The issue was reported through GitLab's HackerOne bug bounty program by the researcher joaxcar.

On October 29, CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities (KEV) catalog "based on evidence of active exploitation." According to BleepingComputer, CISA ordered federal agencies to secure their servers by Sunday, November 1.

According to the Shadowserver Foundation, as reported by BleepingComputer, more than 1,000 GitLab instances are still vulnerable to CVE-2026-97229, out of around 39,000 GitLab instances it sees daily. Shadowserver also counted more than 11,300 instances vulnerable to CVE-2026-110264, another maximum-severity GitLab regular expression compiler bug that BleepingComputer says GitLab fixed last month.

Alpine Linux: an attempted attack and a rebuild

In an incident report dated October 28 and updated October 30, Alpine Linux said someone tried to exploit CVE-2026-97229 against its GitLab server, which hosts the project's aports package repository. According to Alpine's timeline:

• October 13: Alpine upgraded its GitLab instance, but by mistake to 19.3.4, which did not include the fix.
• October 20: The attacker registered an account and started probing GitLab.
• October 21: The main attack attempt. According to Alpine, the crafted CI configurations crashed GitLab worker processes eight times, causing 502 errors and failed CI jobs.
• October 22: Alpine upgraded to 19.3.6, but stayed vulnerable. GitLab patched Ruby, and Alpine's image uses Alpine's own Ruby package, which did not have that patch.
• October 23: The attacker was blocked, and upstream Ruby released fixed versions 3.3.13, 3.4.12 and 4.0.9.
• October 25 and 26: The attacker tried to come back and failed.
• October 26 to 29: After finding the instance was still vulnerable, Alpine closed GitLab to everyone except developers and build servers, rebuilt it from scratch, reset all passwords, replaced GitLab's secret keys, and reopened on October 29 running a newer 19.3 release.

"We have found no evidence that the attacker ran code on the server, but we cannot rule it out," Alpine said. It added that the attacker also downloaded its GitLab container image, "which suggests they were tuning the exploit to our exact build." The project verified that its aports repository, its packages and its October 21 releases (3.21.9, 3.22.7, 3.23.7 and 3.24.3) were not tampered with, and said its signing keys have never been stored on its GitLab server.

If the attack did succeed, Alpine says the data at risk includes user email addresses, names, IP addresses, password hashes, two-factor authentication secrets, CI/CD variables, runner registration tokens, webhook and integration credentials, hashed personal access tokens, and private repositories.

Who is affected

According to GitLab, the following self-managed versions of GitLab CE and EE are affected:

• 19.2 before 19.2.8
• 19.3 before 19.3.5
• 19.4 before 19.4.2

GitLab says GitLab.com is already running the patched version and all GitLab Dedicated tenants were patched before the release was published.

Alpine's experience shows that version numbers are not the whole story. If you build GitLab against your distribution's own Ruby instead of GitLab's bundled one, you may need an updated Ruby as well.

Technical details

According to Rapid7, the root cause is an integer overflow in Onigmo, the regular expression engine used by Ruby. Rapid7 says it validated a full exploit chain that runs an operating system command as GitLab's git user against the official GitLab 19.4.1 CE image, and that the same input did not work against the patched 19.4.2 image. A Metasploit module for the flaw has been submitted on GitHub.

Rapid7 points out an important limit in the "unauthenticated" label. In the chain it showed, the attacker must first be able to commit a malicious .gitlab-ci.yml file and a repository path containing UTF-8 characters to a branch in a public project. Rapid7 notes that an ordinary account can do that by creating a public project on a self-managed instance that allows it. On instances where anyone can sign up, that barrier is low, which matches how Alpine says its attacker began, by registering an account.

What you should do

• Upgrade self-managed GitLab now to 19.4.2, 19.3.5, 19.2.8 or later. GitLab has since published newer patch releases, so take the latest one for your branch. Check the GitLab version actually running after the upgrade, as Alpine found its upgrade had landed on the wrong version.
• If you run GitLab on your distribution's Ruby, make sure Ruby is updated too (3.3.13, 3.4.12 or 4.0.9 upstream). Alpine users of its GitLab image should pull an alpinelinux/gitlab:19.3.6 image dated October 27 or later and run apk upgrade.
• If you can't patch right away, Rapid7 suggests restricting anonymous access to public projects and preventing untrusted users from creating or writing to public projects. Rapid7 says these controls address only the exploit path it demonstrated and are not a fix.
• Look for signs of attack. GitLab has published six threat detections for self-managed customers in its patch release notes, with names such as "Onigmo native worker crash," "Graphql cilint hostile regexp" and "ci regexp oversized non ascii path." Alpine's attack showed up as repeated GitLab worker crashes and 502 errors.
• If you were exposed while unpatched, consider rotating what Alpine rotated: user passwords, CI/CD variables, runner tokens, webhook and integration secrets, and access tokens.

A self-hosted GitLab server often holds the keys to your whole software supply chain, so treat this as an emergency patch.

Sources

• GitLab: GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
• Alpine Linux: GitLab security incident: attempted exploitation of CVE-2026-97229
• CISA: CISA Adds Two Known Exploited Vulnerabilities to Catalog (October 29, 2026)
• Rapid7: CVE-2026-97229: Critical Unauthenticated Remote Code Execution in GitLab
• Rapid7 Analysis: GitLab CI/CD Regex Integer Overflow (CVE-2026-97229)
• BleepingComputer: Over 1,000 GitLab servers vulnerable to ongoing RCE attacks
• BleepingComputer: Alpine Linux rebuilds GitLab after attempted RCE attack

Featured image: Security Breaches original graphic.