Alpine Linux rebuilds GitLab after critical Ruby regex exploit attempt

Alpine Linux announced on 28 October that it completely rebuilt its GitLab server and reset every user password following a targeted attack exploiting a critical vulnerability. The incident highlights a dangerous gap in patching procedures for self-managed instances where the underlying Ruby runtime remains vulnerable even after updating the GitLab application itself.

What happened

An attacker attempted to exploit CVE-2026-97229, a flaw with a perfect CVSS score of 10.0, on Alpine’s own GitLab instance hosting the aports repository. The vulnerability allows remote code execution through crafted regular expressions in CI configurations. Although Alpine found no definitive evidence that the attacker successfully executed code, they could not rule it out due to missing logs and the nature of the exploit. Consequently, they treated the server as compromised, shut it down on 27 October, and completed a full rebuild by 28 October.

The attack began on 20 October, just a week after GitLab released a fix. A newly registered account probed the server, sending malicious CI configurations that crashed worker processes eight times. On 21 October, the attacker caused 502 errors and CI job failures. Alpine blocked the account on 23 October, but the attacker returned on 25 and 26 October. Crucially, Alpine discovered on 26 October that their upgrade to GitLab 19.3.6 on 22 October had not actually fixed the vulnerability because their installation used a standard system Ruby rather than the patched version bundled with GitLab’s official packages.

How it works

The root cause lies in Onigmo, the regular expression engine built into Ruby. CVE-2026-97229 is a bug in this engine that can be triggered by specific regex patterns provided by an attacker in a CI configuration file. When GitLab processes these configurations, it compiles the regex using Ruby. If the Ruby version is vulnerable, this compilation step can lead to remote code execution.

GitLab addressed this in its 12 October release by patching the Ruby interpreter included in its official Linux packages and container images. However, many administrators, including the Alpine team, run GitLab on top of their own system-installed Ruby or custom container images. In these setups, upgrading the GitLab application code does not update the underlying Ruby interpreter. Since the fix resides in the Ruby language itself, servers running unpatched versions of Ruby remain exposed regardless of the GitLab version installed. Alpine’s image used standard Ruby, so their GitLab upgrade left the vulnerable engine intact until they explicitly updated Ruby to version 3.3.13, 3.4.12, or later.

Key details

• Vulnerability: CVE-2026-97229 (CVSS 10.0) in Ruby’s Onigmo regex engine.
• Attack vector: Crafted regular expressions in .gitlab-ci.yml files submitted via CI configuration.
• Patching gap: Upgrading GitLab alone is insufficient for self-compiled installs or custom images; Ruby itself must be updated to 3.3.13, 3.4.12, 4.0.9, or later.
• Incident timeline: Attack probes started 20 October; server closed 27 October; rebuild finished 28 October.
• Data risk: Potential exposure includes user emails, password hashes, 2FA secrets, CI/CD variables, and private repositories if code execution occurred.
• Verification: Alpine verified package integrity from 20 to 24 October against external records, confirming no supply chain compromise in built packages.

Why it matters

This incident serves as a stark reminder for engineering teams managing self-hosted infrastructure. It exposes a common blind spot in dependency management: assuming that updating an application automatically secures its runtime environment. For developers building products with AI or complex CI/CD pipelines, understanding the distinction between application-level patches and runtime-level patches is critical. A failure to update the underlying language interpreter can leave a system wide open to critical exploits, even when the application vendor claims the issue is resolved.

Furthermore, the ambiguity of the outcome underscores the difficulty of forensic analysis in cloud-native environments. Because a successful exploit of this nature might not leave traditional traces like crashes or log entries, organizations must adopt a zero-trust approach to incident response. Alpine’s decision to rebuild from scratch rather than attempt cleanup illustrates the high operational cost of such vulnerabilities. For technical founders and IT leads, this reinforces the need for robust logging, immutable infrastructure practices, and rigorous verification of all components in the software supply chain.

What you can do

• Check your Ruby version: If you run self-compiled GitLab or custom containers, ensure Ruby is updated to 3.3.13, 3.4.12, 4.0.9, or later immediately.
• Verify GitLab upgrades: Confirm that your GitLab installation method bundles the patched Ruby. If not, manually update the system Ruby.
• Rotate secrets: If you suspect exposure, rotate all CI/CD variables, runner tokens, personal access tokens, and webhook credentials.
• Restrict access: Limit anonymous access to public projects and prevent untrusted users from creating or writing to public repositories.
• Monitor for indicators: Use GitLab’s published Sigma detection rules to look for hostile regex patterns, unusually long file paths with non-ASCII characters, and Ruby crash reports.
• Pull updated images: If using Alpine’s GitLab image, pull alpinelinux/gitlab:19.3.6 again, ensuring it was published after 27 October to include the fixed Ruby.