Alpine's GitLab rebuild after RCE try

For two days in late October, someone kept trying to break into the GitLab server that Alpine Linux uses to build and review its software. GitLab processes crashed repeatedly. Some of the attempts came close to landing. When the dust settled, the Alpine team faced a question it could not answer with evidence: had any of them actually worked? The logs that might have shown execution, or ruled it out, were gone. So the project took the slower path and rebuilt the entire server from scratch.

The episode is a study in what happens when a maximum-severity flaw meets a custom deployment, and when the record needed to clear an incident is missing. It also shows how much of the open-source supply chain can rest on a single developer-facing service.

What the attackers were after

The target was CVE-2026-97229, a maximum-severity remote code execution flaw in GitLab. According to the vulnerability's NVD record, the issue is an integer overflow in the CI/CD regular expression compiler Onigmo, which is bundled in Ruby. Under the right conditions, the bug could let an unauthenticated attacker run arbitrary code on the server.

GitLab disclosed the flaw and made fixes available on October 12. The trigger, as GitLab described it, is a specially crafted regular expression submitted through a CI/CD pipeline configuration.

For Alpine, the vulnerable service was not a side project. Its GitLab instance hosts development repositories, code reviews, and CI jobs, including the "aports" build recipes that produce Alpine's software packages. Anything running in or against that environment sits close to the output that downstream users install.

A patch that didn't take

Alpine's first move was to upgrade. The team installed GitLab 19.3.4 rather than the patched version, 19.3.5. A later upgrade to 19.3.6 also failed to close the flaw, because the fix required a patch to Ruby. GitLab bundles Ruby with its official packages, but Alpine's custom container image did not include it. The gap between the vendor's supported build and Alpine's own image left the door open even after the version numbers looked current.

That detail matters beyond Alpine: a version string on a dashboard can suggest a fix is present when the underlying runtime still carries the vulnerable component. Custom container builds are where that assumption breaks.

Eight crashes, four partial hits

On October 20–21, the attacker submitted malicious CI configurations aimed at the flaw. The attempts caused eight worker crashes. Four of them were partially successful, though none appeared to go all the way through to full code execution.

The Alpine team also found that the attackers had downloaded its GitLab container image, a step that suggested they might have been preparing a supply-chain attack rather than a one-off intrusion.

The evidence that wasn't there

When Alpine investigated, it found no tampering in repository commits, packages, or releases up to October 27. It also concluded that no signing keys could have been exposed, since those are not stored on the GitLab server.

What it could not do was prove that no code had run. The logs needed to confirm or rule out execution were missing, and there were no outbound connection records to examine. With the confirming evidence gone, the team could not close the question in its own favor.

"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.

— The Alpine Linux team, in its incident post

What could have been exposed

Alpine listed the information that would be at risk if exploitation had succeeded: user details, password hashes, 2FA secrets, CI/CD secrets, integration credentials, and private project content. None of those exposures has been confirmed. The rebuild and password reset are being treated as precautionary steps taken because the team could not establish the negative.

The distinction is worth keeping straight. "No evidence of compromise" and "no compromise" are different findings, and Alpine's own language reflects the difference.

The numbers behind the response

• CVE-2026-97229 — maximum-severity remote code execution flaw in GitLab's CI/CD regex compiler Onigmo.
• October 12 — date GitLab disclosed the flaw and made fixes available.
• 19.3.4 — GitLab version Alpine initially installed instead of the patched 19.3.5.
• 19.3.6 — later upgrade that still failed to close the flaw because the Ruby patch was absent from Alpine's image.
• October 20–21 — window in which the attacker submitted malicious CI configurations.
• Eight — GitLab worker crashes caused by the attempts.
• Four — crashes that were partially successful, none appearing to complete.
• October 27 — date through which Alpine found no tampering in commits, packages, or releases.
• Ruby 3.3.13 — runtime included in the rebuilt alpinelinux/gitlab:19.3.6 image published October 27.

Why a container image matters

Alpine Linux is a small, lightweight operating system widely used as the base for Docker container images that run applications and services. That footprint makes its build pipeline a consequential place to defend. If someone can alter the recipes or the output that downstream images inherit, the effects can travel far past the Alpine project itself.

The attackers' download of the GitLab container image is the detail Alpine flagged as consistent with preparation for a supply-chain attack. Whether that was the intent is not something the public post establishes; what it does establish is that the team treated the possibility seriously enough to inspect its commits, packages, and releases and to report the result.

What Alpine is telling users to do

The project advises users to reset their GitLab passwords and to pull the alpinelinux/gitlab:19.3.6 image published on October 27. That image contains Ruby 3.3.13 and addresses CVE-2026-97229, closing the runtime gap that the earlier version upgrades left open.

The practical lesson embedded in the timeline is that patching a containerized service means patching everything inside the image, not just the application layer. Alpine's own path to that conclusion ran through three version numbers and a rebuild.

What this means for the rest of us

The uncomfortable part of this incident is not the crash count. It is that a team doing careful work could not answer a basic question — did code run? — because the logs it needed no longer existed. That suggests organizations relying on self-built or custom-patched GitLab images should look at two things before the next maximum-severity disclosure: whether their runtime matches what the vendor actually patched, and whether their logging would survive long enough to rule out execution if an exploit attempt partially succeeded.

For anyone building on Alpine-derived images, the rebuild and password reset are a reminder that the supply chain runs through developer tooling that is often less instrumented than production. This incident did not confirm a compromise, and Alpine's inspections found no tampering. But the response shows what a cautious operator does when the evidence runs out: assume the worst is possible and rebuild rather than argue from absence.