Alpine Linux rebuilds GitLab from scratch after attempted RCE attack

Key points

• Attackers submitted malicious CI configurations against CVE-2026-97229, a maximum-severity unauthenticated remote code execution flaw in GitLab, crashing eight workers on Alpine’s server on October 20-21.
• Alpine found no evidence of code execution or tampering with commits, packages, or releases, but missing logs meant it could not rule out a compromise, so it rebuilt the GitLab instance from scratch and reset all passwords.
• Users should reset their GitLab passwords and pull the alpinelinux/gitlab:19.3.6 image published October 27, which bundles Ruby 3.3.13 and fixes the flaw.

Hackers attempted to exploit a critical GitLab vulnerability in Alpine Linux’s development infrastructure on October 20-21. The open-source project responded by rebuilding its GitLab server and resetting all passwords, because it could not rule out a successful compromise.

Details

The attacks targeted CVE-2026-97229, a maximum-severity integer overflow in GitLab’s CI/CD regular expression compiler Onigmo, bundled in Ruby. The flaw could allow unauthenticated attackers to execute arbitrary code on the server. GitLab disclosed it and made fixes available on October 12, warning that attackers can trigger it under certain conditions by submitting a specially crafted regular expression in a CI/CD pipeline configuration.

Alpine initially installed GitLab 19.3.4 instead of the patched 19.3.5. A later upgrade to 19.3.6 also failed to close the flaw, because the fix required a patch to Ruby that GitLab bundled with its official packages but Alpine’s custom container image did not include. On October 20-21 the attacker submitted malicious CI configurations targeting the flaw, causing eight worker crashes. Four were partially successful, though none seemed to go all the way.

The team found the attackers had downloaded Alpine’s GitLab container image, suggesting they may have been preparing a supply-chain attack. Its investigation found no tampering in repository commits, packages, or releases up to October 27. Signing keys could not have been exposed because they are not stored on the GitLab server. If exploitation succeeded, potentially exposed data includes user details, password hashes, 2FA secrets, CI/CD secrets, integration credentials, and private project content, though no compromise of any of these has been confirmed. “Because we cannot rule out code execution, and the evidence we would need to confirm it no longer exists, we took the harder route and rebuilt the GitLab instance from scratch,” the team explained.

Background

Alpine Linux is a small, lightweight operating system widely used as the foundation for Docker container images that run applications and services. Its GitLab instance hosts development repositories, code reviews, and CI jobs, including the “aports” build recipes used to produce Alpine’s software packages. Tampering with the GitLab environment could affect downstream software, which makes it a valuable supply-chain target.

Why it matters

The incident shows how a custom container image can silently miss a vendor’s bundled fix. Alpine upgraded to 19.3.6 yet remained vulnerable because its image lacked the Ruby patch. Teams running GitLab in a custom image should verify that dependency-level patches actually landed, and treat missing logs as grounds to assume a possible compromise.

What to do

• Reset your Alpine GitLab password.
• Pull the alpinelinux/gitlab:19.3.6 image published October 27, which contains Ruby 3.3.13 and addresses CVE-2026-97229.
• If you run GitLab in a custom image, confirm the Ruby patch for this CVE is included.