Alpine Linux spent a week tearing down and rebuilding its GitLab server after an attacker repeatedly tried to exploit CVE-2026-97229, a maximum severity flaw that lets an unauthenticated user run code on self-managed GitLab instances. The Linux distribution says it found no evidence the attacker succeeded, but it cannot rule it out, and it has reset every password and replaced every secret on the platform.
The disclosure lands as CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 29, giving federal agencies until November 1 to patch.
A regex bug buried in Ruby
CVE-2026-97229 carries a CVSS score of 10.0. The weakness is an integer overflow in Onigmo, the regular expression engine built into Ruby. A specially crafted regular expression in a GitLab CI/CD rules condition compiles into a program larger than the engine can safely track, opening the door to remote code execution without authentication.
The bug is a bypass of an earlier fix for CVE-2026-93577. GitLab patched it on October 12 by updating the Ruby bundled with its official packages. Affected versions include:
- GitLab 19.2 before
19.2.8 - GitLab 19.3 before
19.3.5 - GitLab 19.4 before
19.4.2
The Ruby project followed with upstream regex fixes on October 23 in Ruby 3.3.13, 3.4.12, and 4.0.9. That second step matters. Anyone running GitLab on a system Ruby, rather than the copy GitLab ships, stays vulnerable until Ruby itself is upgraded. CISA’s catalog entry also warns that other products relying on Ruby and Onigmo could be affected.
How Alpine stayed exposed
According to Alpine’s incident report, the project upgraded to GitLab 19.3.4 on October 13 when it meant to install 19.3.5. A week later, a newly registered account began probing the server.
The main attack came on October 21. Alpine recorded 8 worker crashes, 4 of which got partway through the exploit chain, along with 502 errors and failed CI jobs. The attacker also downloaded Alpine’s public GitLab container image, apparently to tune the exploit against the exact build.
An October 22 upgrade to 19.3.6 did not close the hole because Alpine’s image used a standard Ruby package rather than GitLab’s patched build. The account was blocked on October 23. The attacker returned on October 25 and 26 and failed both times, but Alpine discovered on October 26 that the server was still vulnerable.
The team took GitLab offline on October 27 and rebuilt it. By October 28, all passwords had been reset and secret keys replaced. The instance reopened on October 29 running 19.3.7.
Packages and releases checked clean
For a Linux distribution, the biggest question is whether anything shipped to users was touched. Alpine says it verified its aports tree, packages, and releases, and found that releases 3.21.9, 3.22.7, 3.23.7, and 3.24.3, along with packages built between October 20 and 24, were not tampered with. Its package signing keys were never stored on the GitLab server.
That separation kept this from becoming a software supply chain incident like the Mini Shai-Hulud campaign that abused trusted CI pipelines.
What a successful exploit could have reached
Alpine was candid about its blind spots. Relevant logs were no longer available and the server had no outbound traffic logging, so it cannot prove code never ran. If the exploit did succeed, Alpine says exposed data could include:
- User email addresses, names, and IP addresses
- Password hashes and 2FA secrets
- CI/CD variables and runner tokens
- Webhook and mirror credentials
- Personal access token hashes
- Private repositories
Separately, Alpine observed automated login attempts using passwords leaked in other breaches, a reminder that credential stuffing tends to follow any high-profile exposure.
Patching guidance
Self-managed GitLab administrators should move to a fixed release listed in GitLab’s patch release notes and confirm which Ruby their instance actually uses. Alpine re-published its alpinelinux/gitlab:19.3.6 image on October 27 with Ruby 3.3.13, and Alpine users can pull the fixed Ruby package with apk upgrade.
GitLab has also published detection guidance for the flaw. Teams that ran a vulnerable version with open registration should review new accounts, CI job failures, and worker crashes since mid-October, and rotate runner tokens and CI/CD secrets if anything looks off.
Alpine says it will now aim to apply critical patches within a day, improve logging, and sign its release tags. The incident follows a run of high-impact flaws in core infrastructure, including the PHP2Shell vulnerabilities and the Cisco ASA and FTD zero-day.
