Hackers Tuned a Max Severity GitLab Exploit to Alpine Linux's Server, and Upgrading GitLab Alone Won't Stop It

Eight days after GitLab disclosed a perfect 10 severity flaw, an attacker went after Alpine Linux's own GitLab server, and appears to have studied that server's exact build to do it. The attack failed. It still exposed an uncomfortable gap: Alpine had updated GitLab, and the bug was still there.

The attack ran on October 20 and 21, using an exploit for CVE-2026-97229. Alpine has since rebuilt the instance from scratch. "Our checks show that the aports repository, packages, and the October 21 releases were not tampered with," the project said.

Four crashes that came close

The attacker started with a newly registered account and used it to send crafted CI configurations, which crashed the worker process. That fits the catch Rapid7 described when it rebuilt the exploit last month: the attacker needs a way to plant a malicious pipeline file in a public project, and open signup on a server removes most of that obstacle.

Some of the attempts got uncomfortably far. "In 4 of those crashes, the attacker got partway through the exploit and failed at the next step," Alpine said. "The attacker also downloaded our GitLab container image, which suggests they were tuning the exploit to our exact build."

Alpine draws a careful line around what it knows. "We have found no evidence that the attacker ran code on the server, but we cannot rule it out."

That uncertainty explains the scale of the response. Alpine reset all passwords, warning that it has observed automated login attempts using passwords compromised in other leaks. It is still testing the rebuilt instance before releasing it publicly.

The patch that didn't patch

GitLab's October 12 advisory said the flaw "could have allowed an unauthenticated user to execute arbitrary code on the GitLab server" with a specially crafted regular expression in a CI/CD configuration. The root cause is insufficient regular expression validation in Onigmo, Ruby's regular expression engine.

That location is the part many administrators could miss. The bug sits in Ruby rather than in GitLab itself, and Alpine's image runs standard Ruby. So updating to GitLab 19.3.6 did not patch it.

Alpine's warning reaches well beyond its own server. Anyone running GitLab with their own Ruby, whether built from source or packaged in their own container image, must also move to Ruby 3.3.13, 3.4.12, 4.0.9 or later. Upgrading GitLab is not enough on those setups.

A current GitLab version number therefore proves little on such a server. The Ruby version matters just as much.

Three days on the clock

The federal response has now caught up. On Thursday, October 29, CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalog. Its listing gives federal agencies three days to patch under BOD 26-04.

Alpine's account shows how little time that disclosure bought. Within about a week, an attacker with a fresh account was crashing a real project's server and getting partway through the exploit. As far as Alpine can tell, the attempt stopped there.

Some offers on this page may be paid placements or contain affiliate links.