GitLab CVE-2026-97229: Alpine reports an exploit attempt

Alpine Linux says an attacker tried to exploit CVE-2026-97229 on the project's GitLab server on October 20 and 21, 2026. That was about a week after GitLab shipped a fix. The bigger lesson is in Alpine's incident report, published October 28. Upgrading GitLab itself did not close the hole on Alpine's setup, because the real fix is a patch to Ruby.

Alpine is a small Linux distribution that is very popular as a base for Docker containers. Its developers use a self-hosted GitLab server to manage the code for its packages.

What happened on Alpine's server

The attempts crashed GitLab's worker processes eight times, according to Alpine. In four of those crashes, the attacker got partway through the exploit.

Alpine says it found no evidence that the attack worked. "We have found no evidence that it succeeded, but we cannot rule it out," the post says.

So the team treated the server as compromised. It rebuilt GitLab from scratch and limited access to developers and build servers. It also reset all passwords and secret keys.

The project also checked what matters most to its users. Alpine says its aports repository, its packages and its October 21 stable releases were compared against outside records. They showed no sign of tampering. Those releases were Alpine 3.21.9, 3.22.7, 3.23.7 and 3.24.3. The keys that sign Alpine packages were never stored on the GitLab server, and 45 build machines were checked.

Alpine found one more problem along the way. Automated logins on its server used passwords leaked from other websites. Anyone who reused their Alpine GitLab password somewhere else should change it there.

Why the GitLab upgrade did not help

This is the part other self-hosters should read twice. "Upgrading to GitLab 19.3.6 on October 22 didn't fix the vulnerability," Alpine writes.

The reason is how GitLab ships the fix. GitLab's official packages bundle their own copy of Ruby, the programming language GitLab is written in. According to Alpine, the fix for CVE-2026-97229 is a set of patches to that bundled Ruby. Alpine runs GitLab on standard Ruby instead, so a newer GitLab version on its own changed nothing.

Alpine also says it skipped the 19.3.5 update by mistake on October 13. During the attack it was still running 19.3.4. Its own ruby packages now include the fix, and Alpine users should run apk upgrade.

What CVE-2026-97229 is

GitLab disclosed the flaw on October 12, 2026, and urged every self-managed install to upgrade. BleepingComputer reported that it is an integer overflow in the part of GitLab that reads regular expressions in CI/CD pipeline files. Regular expressions are text patterns, and CI/CD pipelines are the scripts that build and test code automatically. GitLab's advisory said the bug "could have allowed an unauthenticated user to execute arbitrary code on the GitLab server."

A researcher using the handle "joaxcar" reported it through GitLab's HackerOne bug bounty program. GitLab.com was already patched, and GitLab Dedicated customers did not need to act.

Item	Detail
Severity	CVSS 10.0, the maximum
Bug type	Integer overflow in the CI/CD regex compiler
Fixed builds	19.2.8, 19.3.4 or 19.3.5, and 19.4.2 (sources differ on 19.3)
Public exploit	Released by Rapid7 on October 13
Exposed hosts	25,766 on vulnerable versions, per Censys

The sources disagree on the 19.3 fix. BleepingComputer lists 19.3.4. Daily Security Review and Alpine both point to 19.3.5. Check GitLab's own advisory for your exact branch.

Daily Security Review reported on October 14 that the exploit relies on a crafted file committed to a branch of a public project. At that time there was no confirmed attack in the wild. The US Cybersecurity and Infrastructure Security Agency (CISA) had not added the bug to its list of exploited flaws either. Censys also found that about 31% of the GitLab hosts it detected were still unpatched.

This is GitLab's second maximum-severity regex flaw this month. GitLab 19.5.1 fixed CVE-2026-110264, a separate CVSS 10.0 bug, on October 21.

What this means for developers

Alpine's report turns a known patch into a working checklist. It also shows that "we upgraded" and "we are safe" are not the same thing.

• Check how your GitLab gets its Ruby. If you run GitLab from source or from distribution packages on system Ruby, the GitLab upgrade alone may not carry the fix. Confirm that your Ruby includes the patches, as Alpine had to.
• Do not skip point releases. Alpine missed 19.3.5 by mistake. Pin your upgrade process to GitLab's security advisories, not to a routine schedule.
• Assume a public server was probed. A public exploit has existed since October 13. If you ran a vulnerable build on the internet after that, review worker crash logs from the following weeks.
• Lock down public projects. The exploit needs a crafted file in a public project. Until you are patched, restrict who can reach the server and turn off public project creation for untrusted users.
• Keep signing keys off the forge. Alpine could say its packages were safe because the signing keys never lived on GitLab. That design choice is worth copying.
• Reset reused passwords. Credential-stuffing logins showed up at Alpine too. Push users toward unique passwords and two-factor login until they are in place everywhere.