Alpine Linux upgraded GitLab and stayed exploitable to CVE-2026-97229 because its image ran standard Ruby. With a Metasploit module public and CISA listing the flaw as exploited, teams running GitLab on their own Ruby should check that Ruby, not only the GitLab version.
What happened
Alpine said a newly registered account sent crafted CI configurations to its GitLab on Oct. 20 and 21, crashing workers 8 times. The instance ran 19.3.4, not the fixed 19.3.5. Alpine upgraded to 19.3.6 on Oct. 22, found it still vulnerable on Oct. 26 and closed it on Oct. 27.
Ruby's maintainers wrote that GitLab fixed this by patching the Ruby it ships, and that Ruby 3.3.13, 3.4.12 and 4.0.9 contain all four GitLab regex fixes. Alpine said GitLab applies the patch "only in its official packages"; Alpine's image used standard Ruby.
Alpine's verdict: "We have found no evidence that it succeeded, but we cannot rule it out." It rebuilt from scratch. Its checks so far, covering Oct. 20 to 24, found no tampering in aports, packages or releases; package signing keys were never stored on the GitLab server, it said.
The flaw, an integer overflow in the size of a compiled regex pattern, lets a crafted CI/CD configuration run code on the server. GitLab's advisory calls it exploitable by an "unauthenticated user". Rapid7's Oct. 16 analysis says the route it demonstrated begins after a push to a public project, and that it does not know how the privately reported attack avoids that. A Metasploit module, referenced in NVD, was merged on Oct. 30, and CISA's KEV entry, added Oct. 29, has a due date of Nov. 1 and marks forensic triage "Yes".
Who is affected
GitLab says CE and EE 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2 are affected, in all deployment types. Another Ruby regex flaw, CVE-2026-110264, was fixed Oct. 21 in 19.5.1, 19.4.3, 19.3.6 and 19.2.9, so the Oct. 12 releases are not enough. Installs from source or on self-built images need their own Ruby upgrade, Alpine said. We found no GitLab guidance on Helm or cloud-native images.
What to do now
- Platform team, today: snapshot the instance and keep its logs, then check which Ruby GitLab runs. Upgrade GitLab to the Oct. 29 releases (19.5.3, 19.4.5, 19.3.7) and Ruby to 3.3.13, 3.4.12 or 4.0.9, or later. Alpine said its 19.3.6 images pulled before Oct. 27 are vulnerable.
- Platform team, until patched: GitLab's advisory lists no workaround as of Nov. 1. Rapid7 suggests restricting credential-free access to public projects attackers can write to, or blocking the lint route, and says route controls do not repair Ruby. Our analysis: also require admin approval for new accounts, as Alpine now does.
- Vulnerability management, today: Ruby said it has not requested CVE IDs for these fixes, so Ruby-CVE scanners miss an old Ruby; track GitLab's CVE IDs instead.
- Security operations, this week: hunt as far back as your logs go, at least to Oct. 12, for Puma worker crashes, 502s, failed CI jobs, new accounts sending CI lint requests, and logins with leaked passwords. GitLab released six detections; Rapid7 adds a roughly 2 GiB worker memory jump or a shell child process. Alpine warned a successful exploit leaves no crash or web-log trace.
- Incident response lead, this week, if you were vulnerable while exposed: follow Alpine's model: rebuild, replace GitLab secret keys, reset passwords and 2FA, and rotate CI/CD variables, tokens, and webhook, mirror and OAuth secrets, then verify repository and build output against records the attacker could not reach.
Ruby said any application that compiles regexes from attacker-controlled strings is exposed, and that Regexp.timeout does not protect against these bugs.
