"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," explained the Alpine Linux team.
CVE-2026-97229, Onigmo, and GitLab CI/CD
The incident centers on CVE-2026-97229, a maximum-severity integer overflow in the Onigmo regular expression compiler bundled with Ruby inside GitLab. GitLab publicly disclosed the flaw and published fixes on October 12, warning that an attacker can trigger the bug by submitting a specially crafted regular expression in a CI/CD pipeline configuration. If successfully exploited, the vulnerability can allow unauthenticated remote code execution on the server running GitLab.
October 20–21: CI jobs crashed, attacker activity detected
On October 20–21, Alpine Linux observed an attacker submitting malicious CI/CD configurations aimed at the Onigmo flaw. The activity repeatedly crashed GitLab worker processes: Alpine recorded eight worker crashes, four of which were described as partially successful attempts, though "none seemed to go all the way." Investigators also observed that the attacker downloaded Alpine’s GitLab container image, a detail the project says suggests possible preparation for a supply-chain attack.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildWhy Alpine rebuilt GitLab and reset credentials
Alpine’s primary operational decision was driven by missing forensic evidence. The team found no clear proof that attackers executed code or altered software packages and releases, but they also lacked the logs and outbound connection records that would definitively rule out compromise. Because those confirming artifacts were not available, Alpine "took the harder route" — rebuilding the GitLab instance from scratch and resetting all passwords. The project also advised users to reset their GitLab passwords.
Patch timeline, container-image pitfalls, and the corrective image
The vulnerability disclosure from GitLab arrived on October 12. Alpine initially installed GitLab 19.3.4 instead of the patched 19.3.5, and a later upgrade to 19.3.6 did not fully close the hole because the ultimate fix required a patch to Ruby. GitLab’s official packages included that Ruby patch, but Alpine’s custom GitLab container image did not. To address the gap, Alpine published and advised users to pull the alpinelinux/gitlab:19.3.6 image on October 27; that image contains Ruby 3.3.13 and, according to Alpine, addresses CVE-2026-97229.
Supply-chain implications and data that might have been exposed
Alpine’s GitLab instance hosts development repositories, code reviews, and CI jobs, including the "aports" build recipes used to produce Alpine’s software packages. That centrality makes the instance a valuable supply-chain target: tampering with the GitLab environment could have downstream effects on software distributed to container-image consumers and others who build on Alpine images.
Alpine listed the categories of data that could have been exposed if exploitation had succeeded: user details, password hashes, two-factor authentication secrets, CI/CD secrets, integration credentials, and private project content. The project reported it had found no tampering in repository commits, packages, or releases through October 27, and noted signing keys were not stored on the GitLab server, so those signing secrets could not have been exposed via this incident.
What this means for technologists, downstream image consumers, and open-source maintainers
- Technologists and security teams: The series of events highlights how a vulnerability in a bundled component (Onigmo in Ruby) can persist even after upstream fixes if custom container images omit required patches. Teams responsible for CI/CD infrastructure should verify not only platform versions but also included language runtimes and their patches.
- Downstream image consumers and enterprises: Because Alpine is widely used as the foundation for Docker container images, consumers who base images on Alpine will want to follow Alpine’s recommendation to pull alpinelinux/gitlab:19.3.6 (published October 27) and to heed the project’s credential-reset guidance.
- Open-source maintainers: The Alpine response underlines an operational choice for projects facing uncertain forensic evidence: when critical traces are missing and risk cannot be ruled out, rebuilding and credential rotation remain viable, if disruptive, mitigations.
Alpine’s investigation found no confirmed tampering through October 27, but the combination of worker crashes, partially successful exploitation attempts, and missing logs left the project unable to exclude a successful compromise. The practical result was a conservative, recovery-first posture: rebuild GitLab, rotate credentials, and publish an updated container image with Ruby 3.3.13. The lingering question the facts leave is whether similar custom-image environments elsewhere contain the same gap between platform updates and bundled runtime fixes — a gap attackers targeted here and one Alpine closed with the October 27 image.
Original reporting: BleepingComputer — Alpine Linux rebuilds GitLab after attempted RCE attack
