Alpine Linux rebuilds GitLab after attempted CVE-2026-97229 exploit

Alpine Linux said an attacker attempted to exploit critical GitLab vulnerability CVE-2026-97229 on its GitLab instance on October 20 and 21. The instance was running GitLab 19.3.4 without the October 12 fix. Alpine found no evidence of success but could not rule it out, so it rebuilt the instance from scratch and reset all passwords.

The vulnerability and attack

CVE-2026-97229 is a critical vulnerability, CVSS 10.0, in how GitLab evaluates regular expressions in CI configuration. The underlying bug is in Onigmo, the regular expression engine built into Ruby. GitLab published fixed releases on October 12, but the fix is a set of patches to the Ruby that GitLab bundles. Upstream Ruby shipped the fix on October 23 in Ruby 3.3.13, 3.4.12 and 4.0.9. After the CVE was published on October 13, Alpine upgraded to 19.3.4 instead of fixed 19.3.5 by mistake.

On October 20 and 21, a newly registered account sent crafted CI configurations to the instance. This crashed GitLab worker processes eight times. In four crashes, the attacker got partway through the exploit and failed at the next step. The attacker also downloaded the GitLab container image, suggesting tuning to the exact build. Alpine found no evidence that code ran on the server, but cannot rule it out.

Why the upgrade did not fix it

Upgrading to GitLab 19.3.6 on October 22 did not fix the vulnerability because the fix is a Ruby patch applied only in GitLab's official packages. Alpine's image used standard Ruby, so it did not get the patch. Operators using their own Ruby need 3.3.13, 3.4.12, 4.0.9 or later. Users of alpinelinux/gitlab should pull alpinelinux/gitlab:19.3.6 again; the image published on October 27 contains Ruby 3.3.13. Earlier 19.3.6 images and all older tags are vulnerable.

Checks and possible exposure

Alpine says aports, packages and the October 21 releases were not tampered with. The October 21 stable releases are 3.21.9, 3.22.7, 3.23.7 and 3.24.3. Packages built from October 20 to 24 came from aports commits verified against records outside GitLab. No signing keys were exposed, and Alpine found no unexpected files, keys, hooks or processes.

Alpine still cannot be sure because a successful exploit would leave no crash and no trace in web logs. Some attack-day logs are gone, including background job logs and the old container's filesystem. There was no logging of outbound network connections, and the hosting provider keeps none. If the attack succeeded, exposed data could include user email addresses, names and IP addresses, password hashes, 2FA secrets, CI/CD variables and runner tokens, credentials for webhooks, integrations and push mirrors, personal access token hashes, and private repositories with confidential issues and merge requests.

Rebuild and user actions

Alpine rebuilt the instance from scratch, reset all passwords and replaced GitLab's secret keys. GitLab is being tested before reopening. When it returns, users must set a new password with 'Forgot your password?' on the sign-in page. Anyone who reused the same password elsewhere should change it there; Alpine has seen automated login attempts using passwords leaked from other sites. Questions can go to [email protected].

Alpine is also changing its process: the rebuilt instance runs Ruby with the fix; critical GitLab security releases should be applied within a day, with checks for Ruby or other component patches; outbound and database connections will be logged and logs kept longer than 14 days; and release tags will be signed. While GitLab is closed, package mirrors, cgit, and mailing lists and IRC are available as normal.

Sources: alpinelinux.org