Distro News

Alpine Linux rebuilds GitLab after near-successful CVE-2026-97229 exploit attempt

Key Takeaway

A critical GitLab vulnerability in Ruby's Onigmo regex engine led to a near-successful attack on Alpine's infrastructure, exposing a gap between GitLab's bundled Ruby patches and standard Ruby distributions.

Summary

On October 20-21, an attacker attempted to exploit CVE-2026-97229, a critical CVSS 10.0 vulnerability in GitLab's CI configuration regex processing, against Alpine Linux's GitLab instance. The instance was running version 19.3.4, which Alpine had mistakenly upgraded to instead of the patched 19.3.5 release. The attacker crashed GitLab worker processes eight times, with four attempts progressing partially through the exploit chain before failing. Alpine treated the instance as potentially compromised and rebuilt it from scratch, completing the rebuild on October 28 with all passwords reset and secret keys replaced.

The incident reveals a significant supply-chain complexity: GitLab's fix for CVE-2026-97229 was not in GitLab's own code but in patches to the Ruby interpreter that GitLab applies only to its official packages and container images. Alpine's custom container image used standard Ruby, so upgrading to GitLab 19.3.6 on October 22 still left the vulnerability unpatched until Ruby upstream released fixes in versions 3.3.13, 3.4.12, and 4.0.9 on October 23. Alpine verified that no packages, releases, or signing keys were compromised, but warns that any organization running GitLab with non-bundled Ruby must patch Ruby separately.

The Ruby patching gap and exploit mechanics

  • CVE-2026-97229 root cause: The vulnerability stems from Onigmo, the regular expression engine embedded in Ruby, not from GitLab's own codebase, making the fix dependent on Ruby interpreter patches rather than GitLab application updates.
  • GitLab's fix distribution model: GitLab published fixed releases on October 12 but only patched the Ruby bundled in its official packages and container images, leaving third-party builds using standard Ruby distributions vulnerable even after GitLab version upgrades.
  • Attack progression: The attacker registered a new account, sent crafted CI configurations causing eight worker process crashes, and downloaded Alpine's GitLab container image to tune the exploit, suggesting reconnaissance and iterative refinement against the specific target build.
  • Detection limitations: A successful exploit would produce no crash logs or web log entries, and critical forensic data including background job logs and the old container filesystem were already lost, preventing definitive confirmation of failure.
  • Remediation requirements: Organizations running GitLab with custom Ruby builds must upgrade to Ruby 3.3.13, 3.4.12, 4.0.9 or later; Alpine's alpinelinux/gitlab:19.3.6 image was republished on October 27 with patched Ruby, but earlier pulls remain vulnerable.

Why it matters

This incident exposes a dangerous assumption in container-based deployments that upgrading the application package suffices for security, when critical fixes may reside in language runtime patches invisible to standard dependency tracking. For Linux distributions and DevOps teams maintaining GitLab from source or custom images, Alpine's experience demonstrates the necessity of verifying whether security fixes apply to bundled versus system components, particularly for Ruby-based applications where interpreter patches are common but poorly documented.

What to do

  • If you run GitLab with your own Ruby, upgrade to Ruby 3.3.13, 3.4.12, 4.0.9 or later.
  • If you use the alpinelinux/gitlab container image, pull alpinelinux/gitlab:19.3.6 again to ensure you have the version published on October 27.

Original reference: alpinelinux.org →