Alpine Linux updated GitLab, but its critical flaw was hiding in Ruby

On October 21, the GitLab server of Alpine Linux, a Linux distribution widely used in containers, started crashing. Pages returned errors and build pipelines failed. Behind the outages, an account created the day before was sending continuous integration configurations crafted to exploit a GitLab vulnerability.

This flaw, CVE-2026-97229, is rated 10 out of 10. According to GitLab, it could allow someone without an account to run code on the server through a booby-trapped regular expression placed in a CI/CD configuration. GitLab released its patch on October 12. On October 29, the US cybersecurity agency (CISA) added it to its catalog of actively exploited vulnerabilities.

Eight crashes, and an uncertainty

Alpine described the incident in detail on its website. The attacker crashed GitLab's processes eight times. Four times, the exploit partly ran before failing at the next step. The attacker also downloaded Alpine's GitLab container image. According to the distribution, this suggests they were tailoring the attack to that specific installation.

Did it work? “We found no evidence of success, but we cannot rule it out,” Alpine writes. A successful exploit would leave neither a crash nor a trace in the web logs. But some of the October 21 logs are missing, and outbound connections were not recorded. Alpine therefore treated its server as compromised.

Why updating GitLab changed nothing

This is the point that concerns many other organizations. The defect is not in GitLab's code but in Onigmo, the regular expression engine built into the Ruby language. GitLab's official packages ship a patched Ruby. Alpine's image used a standard Ruby.

At the time of the attack, the instance was running GitLab 19.3.4. On October 13, Alpine had installed that version by mistake instead of 19.3.5, which contained the fix. And even after moving to GitLab 19.3.6 on October 22, the installation remained vulnerable. “Updating to GitLab 19.3.6 on October 22 did not fix the vulnerability,” Alpine acknowledges. Ruby released its own patches on October 23. The attacker came back on October 25 and 26, without success. On October 27, Alpine closed its GitLab to the public and rebuilt it from scratch.

Alpine states that the keys that sign its packages and releases were never stored on this server. Its repositories, packages and the releases published on October 21 were checked against external copies, with no sign of tampering. All passwords were reset and GitLab's secret keys were replaced.

What should you check on your own GitLab?

If you use GitLab's official packages, apply the patch released by the vendor. If your GitLab runs with a different Ruby (installation from source, a homemade or third-party container image), updating GitLab is not enough:

• upgrade Ruby to version 3.3.13, 3.4.12, 4.0.9 or later;
• if you use the alpinelinux/gitlab image, pull version 19.3.6 again: according to Alpine, any 19.3.6 image retrieved before October 27, and all older versions, are vulnerable;
• on Alpine, run apk upgrade to get the patched Ruby;
• check your logs for unusual CI/CD configurations that crashed your GitLab processes since mid-October;
• on a server open to sign-ups, monitor recently created accounts.

When in doubt, Alpine made the cautious choice: reset all passwords and replace GitLab's secret keys. According to the distribution, CI/CD variables and runner tokens are among the data an attacker could have reached.

How many other servers were targeted?

Alpine is the only known target so far, and it was Alpine's transparency that revealed the attack. CISA does not say whether it has observed other attempts. The flaw actually affects any Ruby program that compiles regular expressions coming from outside: GitLab may simply be the most visible target.