The Alpine Linux project says attackers tried to exploit the maximum-severity GitLab flaw CVE-2026-97229 on its development server on October 20 and 21, and that it could not rule out a successful break-in. Alpine, the small Linux distribution that underpins many Docker container images, hosts its code reviews, CI jobs and the “aports” package recipes on that GitLab instance, which makes it a tempting supply-chain target. Because the evidence needed to confirm or exclude code execution no longer exists, the team rebuilt the server from scratch.
Alpine’s own incident page says the release and package checks came back clean. The October 21 stable releases (3.21.9, 3.22.7, 3.23.7 and 3.24.3) and all packages built from October 20 to 24 came from aports commits that Alpine verified against records the attacker could not reach, including a developer’s clone and all 45 builders. The keys that sign packages and releases are not stored on the GitLab server. Alpine also found no sign that the attacker’s code ran, but a successful exploit would leave no crash or web-log trace, some logs from the attack day are gone, and the project had no logging of outbound connections. Alpine says it is extending its checks to October 27, when it closed GitLab to everyone but developers and build servers.
The timeline explains how the server stayed exposed. GitLab fixed the flaw on October 12, and Alpine upgraded the next day to 19.3.4 instead of the fixed 19.3.5 by mistake. A later move to 19.3.6 still left the instance vulnerable, because the underlying bug is in Ruby’s regular-expression engine and the fix needed a patched Ruby that Alpine’s custom container image did not include. BleepingComputer reports eight worker crashes on October 20 and 21, four of them partially successful, and that the attacker downloaded Alpine’s GitLab container image. Alpine says the attacker’s account was blocked on October 23, return attempts on October 25 and 26 failed, and the rebuilt instance reopened on October 29 on GitLab 19.3.7 with all passwords reset and GitLab’s secret keys replaced.
Had the exploit worked, Alpine says it could have exposed user names, email and IP addresses, password hashes, 2FA secrets, CI/CD variables and runner tokens, integration credentials and private repositories. None of that is confirmed. We covered the flaw itself in GitLab Patches Max-Severity RCE Flaw CVE-2026-97229.
How to check if you’re affected
Affected products are self-managed GitLab servers that run a Ruby build without the fix for CVE-2026-97229, which includes custom or distribution-built GitLab images that did not pick up the Ruby patch, as Alpine’s did not. Upgrading GitLab alone was not enough in Alpine’s case, so confirm the Ruby version inside your GitLab container or package as well as the GitLab version.
Alpine’s page notes that the bug affects any program that compiles regular expressions from untrusted input, not just GitLab. Alpine 3.22, 3.23, 3.24 and edge ship Ruby 3.4.12, and Alpine 3.21 ships Ruby 3.3.13; both include the fix. On Alpine systems, run apk upgrade to pick it up.
If you have an account on Alpine’s GitLab, Alpine says all passwords were reset during the rebuild.