Alpine Rebuilds GitLab After CVE-2026-97229 Attack

Alpine Linux has rebuilt its GitLab server from scratch after an attacker came close to exploiting CVE-2026-97229, the maximum-severity GitLab flaw patched on 12 October. In an incident report dated 28 October, the Alpine team says it found no evidence the attack succeeded, “but we cannot rule it out, so we treated the instance as compromised”.

Alpine is a small Linux distribution widely used as the base for Docker container images. It says its source repository, its packages and its 21 October releases were not tampered with, and that the keys used to sign packages and releases “are not, and never have been, stored on the GitLab server”.

The report carries a warning for anyone who builds GitLab on their own Ruby: upgrading GitLab alone did not close the hole.

What happened

CVE-2026-97229 is a CVSS 10.0 flaw in how GitLab handles regular expressions in CI/CD configuration. TSN covered the original fix when GitLab released it. GitLab’s patch release lists the affected versions as 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2.

On 13 October, Alpine says, it upgraded to GitLab 19.3.4 instead of 19.3.5 “by mistake”, so the server never had the fix. On 20 October a newly registered account began probing it, and on 21 October the main attack came. Crafted CI configurations crashed GitLab worker processes eight times. “In 4 of those crashes the attacker got partway through the exploit and failed at the next step,” the report says. Users saw 502 errors and failed CI jobs. The attacker also downloaded Alpine’s GitLab container image, “which suggests they were tuning the exploit to our exact build”.

Alpine upgraded to GitLab 19.3.6 on 22 October and blocked the attacker’s account on 23 October. The attacker tried to return on 25 and 26 October and failed. On 26 October the team found the server was still vulnerable. It closed GitLab to everyone except developers and build servers on 27 October, finished the rebuild on 28 October, reset all passwords and replaced GitLab’s secret keys.

Why the GitLab upgrade was not enough

The bug sits in Onigmo, the regular expression engine built into Ruby, and GitLab’s fix is a set of patches to the Ruby it bundles. GitLab’s changelog for the 12 October releases lists a “Ruby regexp program size patch for 3.3 and 3.4”. That patch only reaches people who use GitLab’s official packages or images. Alpine’s own image used standard Ruby, so moving to 19.3.6 changed nothing for the flaw.

The Ruby core team shipped the fix upstream on 23 October in Ruby 4.0.9, 3.4.12 and 3.3.13. Its release note says those versions cover the bugs behind four GitLab CVEs, including CVE-2026-97229 and CVE-2026-110264, the second 10.0-rated regex flaw GitLab fixed in October. Ruby says the bugs are reached only when an application compiles a regular expression from a string an attacker controls, and that neither Regexp.timeout nor a limit on pattern length reliably protects against them.

This is the main defensive lesson. Any team that runs GitLab from source or in a container image built on its own Ruby has a second patch to apply. In Alpine’s words: “upgrading GitLab is not enough: you also need Ruby 3.3.13, 3.4.12, 4.0.9 or later.” The same applies to other Ruby programs that build regular expressions from user input, which Ruby lists as calls such as Regexp.new or Regexp.union on untrusted strings. Patch tracking for self-hosted tools therefore has to follow the components inside a release, not only the version number on its front page. Alpine says it will now check each critical GitLab release for Ruby or other component patches its own build must apply, and apply such releases within a day.

What users should do

If you use the alpinelinux/gitlab container image, pull alpinelinux/gitlab:19.3.6 again. Alpine says the image published on 27 October contains Ruby 3.3.13, and any 19.3.6 image pulled before then, plus all older tags, is vulnerable.
On Alpine itself, run apk upgrade. Alpine 3.22, 3.23, 3.24 and edge ship Ruby 3.4.12, and 3.21 ships 3.3.13; both include the fix.
If you reused your gitlab.alpinelinux.org password elsewhere, change it there. Alpine says it has seen automated login attempts using passwords leaked from other sites. All Alpine GitLab passwords have been reset.

What could have been exposed

Alpine explains why it cannot be sure. A successful exploit would leave no crash and no trace in the web logs; some logs from the attack day are gone; and it had no record of outbound network connections. If the attack did succeed, the report says, it could have exposed users’ email addresses, names and IP addresses, password hashes, 2FA secrets, CI/CD variables and runner tokens, integration and mirror credentials, hashed personal access tokens, and private repositories and confidential issues. CI secrets of this kind are a common target, as the recent Gheist campaign against GitHub tokens showed.

To check its packages, Alpine compared every commit added from 20 to 22 October with records the attacker could not reach, a developer’s clone and all 45 build servers. It ran those checks on 24 October and is extending them to 27 October, when GitLab was closed. It also plans to log outbound and database connections, keep logs for longer than 14 days and sign release tags so releases can be verified independently of GitLab. Its package mirrors, cgit and mailing lists stayed available throughout.