Alpine rebuilds GitLab after CVE-2026-97229 attempt; the fix needs patched Ruby

Alpine rebuilds GitLab after CVE-2026-97229 attempt; the fix needs patched Ruby

28 October 2026: Alpine Linux says an attacker tried to exploit CVE-2026-97229 on its GitLab instance on 20 and 21 October, a week after the fix was released, and came close. The project found no evidence that the attack succeeded but could not rule it out, so it rebuilt the instance from scratch, reset every password and replaced GitLab's secret keys; the rebuild was completed on 28 October. Its report carries a warning for anyone who runs GitLab outside GitLab's own packages.

Not yet independently verified. This rests on Alpine Linux's own incident report. We did not re-read GitLab's documentation on installations that bring their own Ruby for this item. We will update this when it can be confirmed, and remove this note.

Why the upgrade did not fix it

CVE-2026-97229 is a critical (CVSS 10.0) flaw in how GitLab evaluates regular expressions in CI configuration. The bug is in Onigmo, the regular expression engine built into Ruby. GitLab published fixed releases on 12 October, but the fix is a set of patches to the Ruby that GitLab bundles in its own packages and container images. Upstream Ruby shipped the fix on 23 October.

Alpine's instance used standard Ruby in its own image. It had upgraded to 19.3.4 on 13 October instead of 19.3.5, which had the fix, by mistake; the attack came on 20 and 21 October, crashing worker processes eight times. Upgrading to GitLab 19.3.6 on 22 October still did not fix it, and on 26 October the instance was found to be vulnerable. Alpine's advice: if you run GitLab with your own Ruby, from source or in your own container image, you also need Ruby 3.3.13, 3.4.12, 4.0.9 or later. Users of the alpinelinux/gitlab image should pull 19.3.6 again; the image published on 27 October contains Ruby 3.3.13, and any copy pulled before then, and all older tags, are vulnerable.

What Alpine checked

Alpine says its releases and packages were not modified. Every aports commit added from 20 to 22 October came through a recorded push by a known developer, checked against a developer's clone and all 45 builders. The 21 October stable releases (3.21.9, 3.22.7, 3.23.7 and 3.24.3) and every package built from 20 to 24 October came from those verified commits. Package and release signing keys have never been stored on the GitLab server.

The report is candid about the limits. A successful exploit would leave no crash and no trace in web logs, some logs from the attack day are gone, and there was no logging of outbound connections. Had it succeeded, user emails, names and IP addresses, two-factor secrets, CI/CD variables, runner tokens, integration and mirror credentials and private repositories could have been exposed. The attacker returned on 25 and 26 October and failed.

What other GitLab operators should take from it

Self-managed GitLab installed from GitLab's official packages gets the Ruby patch with the upgrade. Installations built from source, community container images and distribution packages that use the system Ruby do not, and their operators should check the Ruby version as well as the GitLab version. Anyone who reused their gitlab.alpinelinux.org password elsewhere should change it there.

Related on TrustList:

• Gheist campaign uses stolen GitHub tokens to dump Actions secrets
• Jenkins 2.588 and LTS 2.580.2 fix 15 core flaws, including XStream code execution
• PingCAP breach: TiDB Cloud users told to replace API keys now

Sources

• Alpine Linux: GitLab security incident, attempted exploitation of CVE-2026-97229 (28 October 2026), 28 October 2026