Alpine Linux rebuilt its GitLab server from scratch and reset every password after an attacker probed CVE-2026-97229, a CVSS 10 flaw in the Ruby regex engine GitLab uses for CI configs. Alpine had upgraded GitLab, but its image lacked the Ruby patch. Fixed Ruby versions are 3.3.13, 3.4.12 and 4.0.9.
If you run GitLab on your own server, upgrading GitLab may not close CVE-2026-97229. The bug lives in Onigmo, the regex engine built into Ruby, and Alpine Linux learned that its GitLab image stayed exposed after two upgrades because the Ruby underneath was never patched. Check that your GitLab runs on Ruby 3.3.13, 3.4.12 or 4.0.9 or later, then rotate the secrets your CI pipelines hold.
What happened at Alpine
Alpine Linux, the small distribution behind many Docker base images, published an incident report on October 28. Confirmed by Alpine:
- October 12: GitLab released a fix for CVE-2026-97229, a CVSS 10.0 flaw in how GitLab evaluates regular expressions in CI configuration.
- October 13: Alpine upgraded its server to GitLab 19.3.4 by mistake. The fix was in 19.3.5.
- October 20 and 21: an attacker registered an account and submitted crafted CI configurations. They crashed GitLab worker processes eight times, and four attempts got partway through the exploit.
- October 22: Alpine moved to GitLab 19.3.6. That still did not close the hole, because the fix is a Ruby patch its custom image did not include.
- October 23: upstream Ruby shipped the fix and Alpine blocked the attacker’s account. The attacker returned on October 25 and 26 and failed.
- October 27 to 29: Alpine shut GitLab down, rebuilt it from scratch, reset all passwords, replaced GitLab’s secret keys and reopened on 19.3.7.
Alpine says it found no evidence the attacker’s code ran, and it cannot rule it out because some logs from the attack day are missing. In its words, “we treated the instance as compromised and rebuilt it from scratch.”
Your Alpine packages are fine
Alpine checked its package repository, the October 21 releases and their ISO and minirootfs images against outside records and found no tampering. Its signing keys never lived on the GitLab server. If you build on Alpine images, nothing needs to change.
If you had an account on Alpine’s GitLab, the exposure list is longer: names, emails and IP addresses, password hashes, 2FA secrets, CI/CD variables and runner tokens, and integration credentials, all “if the attack succeeded.” Set a new password with “Forgot your password?” and change it anywhere you reused it. Alpine says a separate post will list what else to set up again. BleepingComputer also reports the attacker downloaded Alpine’s GitLab container image.
Check the Ruby under your GitLab
Alpine’s lesson applies to any team that runs GitLab from a custom image or from source on a distribution’s Ruby:
1. Check the Ruby version. Fixed releases are Ruby 3.3.13, 3.4.12 and 4.0.9. On Alpine hosts, apk upgrade gets you there: Alpine 3.21 ships 3.3.13, and 3.22 through edge ship 3.4.12.
2. Re-pull Alpine’s GitLab image if you use it. The alpinelinux/gitlab:19.3.6 image published on October 27 carries the fixed Ruby. Any 19.3.6 pulled before that date, and every older tag, is still vulnerable.
3. Look for crashed workers. Repeated GitLab worker crashes after a CI config push were Alpine’s first sign. Search your logs from October 13 on.
4. Rotate CI secrets if you were exposed. CI/CD variables and runner tokens are what an attacker would take first. If you can’t prove you were patched before October 20, rotate them.
Upgrading the app is half the patch
Our read, as inference: two GitLab upgrades left Alpine’s server open because the fix sat in the language runtime underneath. Any team that builds its own images for self-hosted tools has the same blind spot. It’s the second CVSS 10 server flaw we’ve covered this week, after LXD and MicroCloud. A CI server holds deploy keys and cloud credentials, and as the Northflank breach showed, stolen keys get used the same day.
Reported by BleepingComputer, with Alpine Linux’s incident report as the primary source.