Alpine Linux rebuilt its GitLab after CVE-2026-97229 RCE attack

Alpine Linux rebuilt its GitLab development instance from scratch after attackers spent nearly a week trying to exploit CVE-2026-97229, the CVSS 10.0 unauthenticated RCE in GitLab's CI/CD regex handling. Alpine found no evidence that the attacker ran code or tampered with packages — but says it cannot fully rule it out, because some logs from the attack day are gone and outbound connections were never recorded.

The account is Alpine's own, published in the project's GitLab security incident post; BleepingComputer corroborates the timeline.

The vulnerability

CVE-2026-97229 is an integer overflow in Onigmo, the Ruby regular-expression engine GitLab bundles. A specially crafted regex in a CI/CD pipeline configuration can trigger it, giving an unauthenticated attacker code execution on the server. GitLab shipped fixed releases on October 12. We covered the CVE itself when it landed — see the disclosure and its promotion to CISA KEV.

The Alpine incident is a textbook example of why patching GitLab wasn't enough. The fix is a Ruby patch. GitLab applies it inside its own official packages, but Alpine ran its custom container image with a standard Ruby — so upgrading GitLab left the hole open.

What happened

Alpine's timeline:

• Oct 13 — CVE published; Alpine upgraded to 19.3.4 by mistake instead of the patched 19.3.5.
• Oct 20 — a newly registered account starts probing.
• Oct 21 — main attack: crafted CI configurations crash GitLab worker processes, throwing 502 errors and failed CI jobs.
• Oct 22 — Alpine upgrades to 19.3.6; the flaw stays open because the image's Ruby lacks the patch.
• Oct 23 — attacker's account blocked; Ruby ships its fix.
• Oct 25–26 — attacker returns; attempts fail. Alpine finds the instance is still vulnerable.
• Oct 27 — GitLab closed to all but developers and build servers.
• Oct 28 — rebuild complete; all passwords reset and secret keys replaced.
• Oct 29 — GitLab reopened at 19.3.7.

In total, the attacker crashed GitLab workers 8 times; in 4 of those they got partway through the exploit before failing at the next step. They also downloaded Alpine's GitLab container image — which Alpine reads as the attacker tuning the exploit to that exact build, a possible precursor to a supply-chain attack.

What Alpine could and couldn't confirm

Alpine verified that its releases (3.21.9, 3.22.7, 3.23.7, 3.24.3, published Oct 21) and their ISO and minirootfs images were not modified; that packages built Oct 20–24 and aports commits Oct 20–22 match records held outside GitLab; and that package-signing keys were never stored on the GitLab server, so they could not have leaked.

What it can't rule out: a successful exploit would leave no crash and no web-log trace, some attack-day logs are missing, and neither Alpine nor its host logged outbound connections. Had the attack succeeded, exposed data would have included all users' emails, names and IPs, password hashes, 2FA secrets, CI/CD variables, runner tokens, webhook and integration credentials, personal access tokens (hashed), and private repositories.

Action checklist

1. Reset your Alpine GitLab password via "Forgot your password?" once the instance is back, and change it anywhere you reused it.
2. Re-pull alpinelinux/gitlab:19.3.6 — the image published October 27 ships Ruby 3.3.13 and fixes this. Any 19.3.6 image pulled before Oct 27, and all older tags, remain vulnerable.
3. Self-managed GitLab on a custom image: upgrading GitLab is not sufficient. Run Ruby 3.3.13, 3.4.12, 4.0.9, or later.
4. On Alpine hosts: apk upgrade — 3.21 ships Ruby 3.3.13; 3.22, 3.23, 3.24, and edge ship 3.4.12.

Context

This is the predictable second act of CVE-2026-97229: a maximum-severity, unauthenticated RCE in CI infrastructure, already in CISA's KEV catalog, landing on a high-value open-source target whose compromise would ripple downstream to every distro user. The detail other coverage underplays is that Alpine did everything the headline advice said — it upgraded GitLab twice — and stayed exploitable both times, because the fix lived in a dependency the vendor's packaging quietly patches and a custom image does not. If you run GitLab from anything other than the official omnibus package, the Ruby version is the control that matters here, not the GitLab version number.