On October 20, a freshly registered account began probing Alpine Linux's GitLab instance with crafted CI configurations designed to exploit CVE-2026-97229, a CVSS 10.0 vulnerability in Onigmo, the regular expression engine bundled with Ruby. The attacker crashed GitLab worker processes eight times. In four of those crashes, the exploit chain advanced partway before failing at the next step. The attacker also pulled Alpine's GitLab container image — a strong signal they were calibrating the exploit to the exact build. The vulnerability had been public since October 13. GitLab shipped fixed releases on October 12. Alpine's team upgraded to GitLab 19.3.4 instead of 19.3.5 — the version that contained the fix — a human error that left the door open for eight days. When they upgraded again to 19.3.6 on October 22, the vulnerability persisted because the fix lives in a Ruby patch that GitLab applies only in its official packages. Alpine's custom-built image used standard Ruby, which didn't receive the patch until October 23. This is the core lesson: GitLab's security model assumes you're running their packages. If you build from source or use your own container image, upgrading GitLab is not enough. You need Ruby 3.3.13, 3.4.12, 4.0.9, or later. Alpine's own alpinelinux/gitlab:19.3.6 image was vulnerable until the October 27 rebuild. Any copy pulled before that date remains exposed. Alpine's response was aggressive and honest. Despite finding no evidence of code execution — no unexpected files, keys, hooks, or processes — the team treated the instance as compromised and rebuilt from scratch. The rationale is straightforward: a successful exploit would leave no crash and no trace in web logs. Background job logs from the attack day are gone. The old container's filesystem is gone. There was no logging of outbound network connections, and the hosting provider keeps none either. The absence of evidence is not evidence of absence. The verification of downstream integrity is solid. Every aports commit from October 20-22 was cross-referenced against a developer's clone and all 45 build servers — records the attacker could not reach. Every package built October 20-24 on every architecture traced back to verified commits. The October 21 stable releases (3.21.9, 3.22.7, 3.23.7, 3.24.3), including ISO images and minirootfs tarballs used by official Docker images, were clean. Signing keys were never stored on the GitLab server. The potential blast radius if the exploit succeeded was enormous: email addresses, names, IP addresses of all users; password hashes; 2FA secrets; CI/CD variables and runner tokens; webhook and integration credentials; personal access tokens; every private repository and confidential issue. All passwords have been reset. Anyone who reused their gitlab.alpinelinux.org password elsewhere needs to change it — the team observed automated login attempts using credentials leaked from other sites. Alpine is making four concrete changes: the rebuilt instance runs patched Ruby, critical security releases will be applied within one day with component-level verification, outbound connection and database logging will be added with retention beyond 14 days, and release tags will be cryptographically signed for independent verification. These are the right moves. The missing outbound connection logs are the single biggest gap in the post-mortem — the one data source that could have provided certainty about whether data left the building.
