Alpine Linux's self-hosted GitLab was attacked through a Ruby regex bug

If you run your own GitLab from source, upgrading GitLab last week was not enough. Alpine Linux said on 28 October that an attacker tried to exploit a critical GitLab bug on its own instance. The attempts came on 20 and 21 October. Alpine said it has no proof the attack succeeded. It also said it cannot rule that out. So it rebuilt the server from scratch and reset every password.

The bug is CVE-2026-97229. GitLab rates it critical, CVSS 10.0. It sits in Onigmo, the regular expression engine built into Ruby. A crafted CI configuration can run code on the server. GitLab released a fix on 12 October. The fix is a set of patches to the Ruby that GitLab bundles in its own packages. Upstream Ruby released the fix on 23 October, in versions 3.3.13, 3.4.12 and 4.0.9.

Why the GitLab upgrade did not help

Alpine upgraded to GitLab 19.3.6 on 22 October and was still vulnerable. The fix is not in GitLab's own code. It is in a patch to Ruby that GitLab applies only when you install from GitLab's packages. Alpine's image used standard Ruby, so the patch never applied.

Alpine said any site running GitLab from source needs Ruby 3.3.13, 3.4.12, 4.0.9 or later. The same holds for a site running GitLab in its own container image. The GitLab upgrade on its own is not enough. Sites that use GitLab's own packages are fine. So is the alpinelinux/gitlab:19.3.6 image published on or after 27 October.

What the attacker did

A newly registered account sent crafted CI configurations to Alpine's GitLab. GitLab worker processes crashed eight times. Alpine said that in four of those crashes the attacker got partway through the exploit. Each time the attack failed at the next step. The attacker also downloaded Alpine's GitLab container image. Alpine said this looks like the attacker was tuning the exploit to Alpine's exact build.

Alpine said timing probes showed no delays. It also said it found no unexpected files, keys, hooks or processes. Alpine said a successful exploit would leave no crash and no web log trace. Some logs from the attack day are already gone.

What was not tampered with

Alpine said no package or release was changed. Every aports commit added on 20 to 22 October arrived through a recorded push by a known developer. Alpine said it checked each commit against a developer's own clone and all 45 build servers. Every package built from 20 to 24 October, on every architecture, came from commits as published on git.alpinelinux.org. Alpine said the 21 October stable releases are 3.21.9, 3.22.7, 3.23.7 and 3.24.3. The ISO images and minirootfs tarballs behind the official Alpine Docker image were built from the same commits.

Alpine said the keys that sign its packages and releases were not on the GitLab server at any point.

What to do if you had an account

Alpine said the server will reopen soon with every password reset. A visitor will need to use "Forgot your password?" on the sign-in page. Alpine said it has seen automated login attempts with passwords leaked from other sites. Any password used on gitlab.alpinelinux.org and also on another site should be changed on the other site.

Alpine said it is making four changes. It will run the fixed Ruby on the rebuilt instance. It will apply critical GitLab security releases within a day. It will record outbound connections from the GitLab host and the database, and keep logs longer than 14 days. And it will sign release tags, so a release can be verified without going through GitLab.

Source

Alpine Linux: GitLab security incident, attempted exploitation of CVE-2026-97229.