Alpine Rebuilds GitLab After Attempted CVSS 10.0 Exploit
Alpine Linux rebuilt its GitLab server, reset every account password and replaced GitLab secret keys after an attacker attempted to exploit CVE-2026-97229, a GitLab vulnerability rated CVSS 10.0. Alpine found no evidence that the attempt achieved code execution, but said it could not rule it out and completed the rebuild on 28 October.
The affected host, gitlab.alpinelinux.org, contains aports, the repository used to build Alpine packages. Alpine said package-signing and release-signing keys were never stored on the GitLab server. It also verified aports changes added from 20 to 22 October against developer copies and records from all 45 build servers, and said packages built from 20 to 24 October matched the published aports changes.
Crafted CI configurations triggered worker crashes
Alpine said a newly registered account began probing the server on 20 October, when it was still running GitLab 19.3.4. The account submitted crafted CI configurations on 20 and 21 October, causing GitLab worker processes to crash eight times. The principal attempt on 21 October also produced 502 errors and made CI jobs fail.
In four crashes, the attacker progressed partway through the exploit before failing at a subsequent stage, Alpine said. The party also downloaded Alpine's GitLab container image, which Alpine said suggested an effort to tune the exploit for its exact build. The account was blocked on 23 October; subsequent attempts to regain access on 25 and 26 October failed.
The project had upgraded the service to GitLab 19.3.6 on 22 October, but discovered on 26 October that it remained vulnerable. On 27 October, it restricted access to developers and build servers while rebuilding the instance. The new deployment runs Ruby 3.3.13 or later and was being tested before reopening to the public.
Why the GitLab update did not close the vulnerability
CVE-2026-97229 involves Onigmo, the regular-expression engine included in Ruby. GitLab processes regular expressions in CI configurations with Ruby. GitLab's patches applied to the Ruby bundled in its Linux packages and official container images, but Alpine's image used standard Ruby rather than GitLab's bundled runtime.
That distinction meant upgrading GitLab alone did not change the vulnerable Ruby installation. Alpine said self-compiled GitLab deployments and container images that install Ruby separately must update both GitLab and Ruby. Fixed Ruby versions are 3.3.13, 3.4.12 and 4.0.9, or later; Ruby 3.2 has reached end of life and will not receive a fix.
Exposure assessment and administrator actions
Alpine reported no timing delays from probes, no unexpected files, keys, hooks or processes, and no visible web or API transfer of private data. However, some attack-day logs and the old container filesystem were unavailable, while neither Alpine nor its hosting provider had recorded outbound network connections. A successful exploit could leave neither a crash nor useful web-log evidence, so Alpine treated the server as potentially compromised.
GitLab's advisory states that, under certain conditions, the flaw could allow unauthenticated code execution. Rapid7 demonstrated a laboratory exploit against an unpatched official GitLab 19.4.1 image, running commands as the git user; the same input failed on patched 19.4.2. In that tested path, an attacker first needed write access to place a malicious .gitlab-ci.yml file and a UTF-8 path in a public-project branch.
Administrators using GitLab Linux packages or official images should move to the newest release on their branch. Administrators running self-compiled installations or their own Ruby-based images must also update Ruby to a fixed release. Where code-execution indicators exist, GitLab advises treating the server as compromised and rotating GitLab secrets, CI/CD variables, runner tokens and access tokens. The practical implication is to verify the runtime actually used by every GitLab deployment, because an application upgrade may not patch a separately managed dependency.