Alpine Linux rebuilds its GitLab after an attempted exploit of a critical vulnerability

The Alpine Linux team has published an incident report about its own GitLab server. On October 20 and 21, an attacker tried to exploit CVE-2026-97229 — a week after a fix had been released. According to the developers, the attack came close to working. They found no evidence that it succeeded but cannot rule it out, so they treated the instance as compromised and rebuilt it from scratch. Their checks show that the aports repository, packages and the October 21 releases were not tampered with.

A vulnerability the upgrade didn't fix

CVE-2026-97229 is a critical vulnerability rated CVSS 10.0. It concerns how GitLab evaluates regular expressions in CI configuration. The underlying bug lives in Onigmo, the regular expression engine built into Ruby. GitLab shipped fixed releases on October 12, but the fix is actually a set of patches to Ruby. Those patches only reach GitLab's official packages and container images. Upstream Ruby shipped the fix on October 23, in versions 3.3.13, 3.4.12 and 4.0.9.

On October 13 the Alpine team mistakenly upgraded to GitLab 19.3.4 instead of 19.3.5, which already contained the fix. A week later, a newly registered account began submitting crafted CI configurations. GitLab worker processes crashed eight times, and in four of those cases the attacker got partway through the exploit before failing at the next step. The attacker also downloaded Alpine's GitLab container image — apparently to tune the exploit to that exact build.

On October 22 the server was upgraded to 19.3.6, but that didn't help: Alpine's image used standard Ruby without the patch. The problem was discovered on October 26. By then the attacker's account had already been blocked, and attempts to get back in on October 25–26 failed. On October 27 GitLab was closed to everyone except developers and build servers. The rebuild was completed on October 28, with all passwords reset and GitLab's secret keys replaced.

What is known and what can't be ruled out

The stable releases 3.21.9, 3.22.7, 3.23.7 and 3.24.3 — including ISO images and the minirootfs tarballs the official alpine Docker images are built from — as well as all packages built from October 20 to 24, were checked against records outside GitLab: a developer's clone and all 45 builders. Package signing keys have never been stored on the GitLab server. No signs of foreign code execution or of data leaking through web or API requests were found.

Certainty is out of reach, however. A successful exploit would leave neither a crash nor a trace in the web logs. Some logs from the attack day are gone, and outbound network connections were not logged — neither by the team nor by its hosting provider. In the worst case, exposed data could include users' email addresses, names and IP addresses, password hashes, 2FA secrets, CI/CD variables, runner tokens, webhook and integration credentials, as well as private repositories and confidential issues.

What users should do

Once GitLab reopens, users will need to set a new password via "Forgot your password?". Anyone who reused that password elsewhere is advised to change it there too: automated login attempts using passwords leaked from other sites have already been seen against Alpine's GitLab. Those running GitLab with their own Ruby need more than a GitLab upgrade — they also need a patched Ruby. The alpinelinux/gitlab:19.3.6 image should be pulled again: only the image published on October 27 is fixed. Ruby packages in Alpine 3.21–3.24 and edge already include the fix and can be updated with apk upgrade.

Going forward, the team promises to apply critical GitLab security releases within a day and to check them for patches to bundled components. It will also expand logging, keep logs longer than 14 days and start signing release tags so releases can be verified independently of GitLab.

Source: Lobsters