An attacker nearly exploited the CVSS 10 GitLab CI regex flaw on Alpine Linux's own GitLab; Alpine rebuilt the server and reset every password, and says packages and releases were not tampered with
A newly registered account sent crafted CI configurations to gitlab.alpinelinux.org on Oct 20 and 21, crashing GitLab workers 8 times; in 4 of them the exploit got partway and failed at the next step. The attacker also downloaded Alpine's GitLab container image, which Alpine reads as tuning the exploit to its exact build, and came back on Oct 25 and 26 without success. Alpine found no unexpected files, keys, hooks or processes but treated the instance as compromised.
- Why the upgrade did not help: GitLab's Oct 12 fix for CVE-2026-97229 is a patch to the Ruby (Onigmo regex engine) that GitLab bundles in its own packages and images. Alpine's image used standard Ruby, so upgrading to GitLab 19.3.6 on Oct 22 left it vulnerable. Upstream Ruby shipped the fix on Oct 23 in 3.3.13, 3.4.12 and 4.0.9.
- Supply chain: Alpine says aports, packages built Oct 20 to 24 and the Oct 21 releases (3.21.9, 3.22.7, 3.23.7, 3.24.3, including the minirootfs used for the official Docker images) match records kept outside GitLab. Package and release signing keys have never been on the GitLab server.
- Users: all gitlab.alpinelinux.org passwords were reset and GitLab secret keys replaced. Change the password anywhere you reused it; Alpine has seen credential-stuffing attempts.
What to do: if you run GitLab on your own Ruby (source installs or custom images), upgrading GitLab is not enough; you also need one of those Ruby releases. Users of the alpinelinux/gitlab image must pull 19.3.6 again; images pulled before Oct 27 are still vulnerable.
Sources: Alpine Linux: GitLab security incident, attempted exploitation of CVE-2026-97229 (Oct 28) · Ruby: Regexp fixes for GitLab CVEs (Oct 23)