Alpine Linux said an attacker tried to exploit CVE-2026-97229 on its GitLab instance on 20 and 21 October, about a week after GitLab released fixes, and that it rebuilt the service because it could not rule out success.

The project said the attack came close to working. GitLab worker processes crashed eight times, and in four of those crashes the attacker got partway through the exploit before failing at the next step. Alpine also said the attacker downloaded its GitLab container image, which suggests the exploit was being tuned to that exact build.

What the flaw is

CVE-2026-97229 is a critical vulnerability in how GitLab evaluates regular expressions in CI configuration. GitLab scored it 10.0, the maximum, and described possible code execution by an unauthenticated user. The underlying bug is in Onigmo, the regular expression engine built into Ruby.

GitLab released fixed versions on 12 October: 19.4.2, 19.3.5 and 19.2.8. The advisory covers GitLab CE and EE from 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2, and says all deployment types are affected unless stated otherwise. GitLab.com was patched before disclosure, and Dedicated customers did not need to act. Rapid7 says the issue was reported through HackerOne by joaxcar.

The fix is a set of patches to the Ruby runtime that GitLab bundles in its official packages and container images. Upstream Ruby shipped its own fix on 23 October, in Ruby 3.3.13, 3.4.12 and 4.0.9.

How the exploit chain works

Rapid7 built an end-to-end proof of concept that ran arbitrary commands as GitLab's git operating-system account on the official Linux amd64 gitlab/gitlab-ce:19.4.1-ce.0 image with ASLR enabled. The route starts with GitLab's CI rules that match repository paths, such as rules:exists:regexp and rules:changes:regexp, placed on a conditional include.

GitLab's matcher expands the attacker's pattern, compiles it with Ruby's regular expression engine, and tests it against file paths in the repository. Several checks sit in front of that compile step. The source length is checked, subroutine calls are rejected, and a scanner looks for large repeat counts. That scanner only recognises contiguous digits.

The Rapid7 pattern hides its quantifier bound inside an inline regular expression comment: {5(?#)7805}. Onigmo ignores the comment and reads the bound as 57,805, while the scanner does not see a number above 1,000. The checked expression stays under a kilobyte.

The size problem appears later. Six [[:word:]] classes expand when Ruby matches the pattern against paths containing valid four-byte UTF-8 characters. Ruby recompiles the expression for that encoding, each POSIX word class expands into a large Unicode table, and GitLab does not size-check the new program. One copy of the repeated body is 37,151 bytes. Multiplied by 57,805, that is 2,147,513,555 bytes, which is 29,908 bytes beyond signed 32-bit INT_MAX. The size check goes negative, so it treats the expansion as small enough and emits all 57,805 copies.

The payload sits in character classes that compile into chosen bitmap bytes. A misplaced jump at the end of the expanded branch lands in one of those bitmaps, and Onigmo executes the attacker's bytes as instructions. Rapid7 calls the result a controlled redirect of the regex engine's backtracking stack.

What the attacker needed first

The public route Rapid7 documented is not fully unauthenticated. It begins after an attacker has pushed both the malicious CI configuration and a specially named path to a public project; only the final CI lint request is unauthenticated. Rapid7 notes that this prerequisite conflicts with GitLab's PR:N rating, and because the underlying HackerOne report remains private, it does not know how the reported attack avoids that step.

What Alpine saw

Alpine's GitLab was running 19.3.4 and did not have the 12 October fix. On 20 and 21 October a newly registered account sent crafted CI configurations to the instance. The configurations crashed GitLab worker processes eight times. In four crashes the attacker got partway through and failed at the next step, and the downloaded container image suggests the attempt was being adjusted to Alpine's build.

Alpine found no evidence that the attacker ran code on the server, but said it could not rule it out, so it treated the instance as compromised and rebuilt it from scratch. The project reset all passwords and warned that automated login attempts had been made against its GitLab using passwords leaked from other sites. It also checked its aports repository, packages and the 21 October releases and found no tampering. Those checks covered commits from 20 to 22 October; because the instance stayed vulnerable until 27 October, Alpine extended them to that date.

The upgrade trap

Alpine upgraded to GitLab 19.3.6 on 22 October and found that the vulnerability remained. The fix is not in GitLab's own code but in a patch to Ruby that GitLab applies only in its official packages. Alpine's image used standard Ruby, so the upgrade did not deliver the patch.

The GitLab version alone is not enough. If an operator runs GitLab with a Ruby they built or packaged, they also need Ruby 3.3.13, 3.4.12 or later. For Alpine's image, 19.3.6 pulls before 27 October and all older tags are vulnerable; the 27 October image has Ruby 3.3.13.

What operators should check

Start with two versions: the GitLab release and the Ruby runtime behind it. A 19.4.2, 19.3.5 or 19.2.8 release built against an unpatched Ruby does not close the flaw. Operators who run their own images should rebuild them on a patched Ruby and confirm the runtime version inside the container.

Container users should re-pull the vendor image and compare the digest with the advisory. Alpine's note is specific: pulling 19.3.6 again after 27 October gets the patched image, while an earlier pull does not.

Then look at exposure. Rapid7's public route needs a public project that accepts pushes, so review which projects accept outside contributions. Check CI lint requests, worker crashes and unusual account creation around 20 and 21 October.

The Ruby surface is wider than GitLab. Alpine says any program compiling regular expressions from untrusted input is exposed, and its Ruby packages in 3.21 through edge now include the fix; apk upgrade is the action.

What is not known

Alpine cannot say whether the exploit succeeded. The evidence needed to confirm or exclude code execution no longer exists, which is why the project rebuilt the instance. GitLab's release notes did not report wild exploitation at disclosure. The identity of the attacker is not public, and neither is the number of other organisations targeted.

GitLab's release notes did not report exploitation in the wild at disclosure, and Rapid7's analysis covers one documented route.

What happens next

Alpine is testing its GitLab before reopening it, and users will reset passwords through the sign-in page when it returns.