CVE-2026-97229: Alpine rebuilt GitLab and reset every password

Alpine Linux rebuilt its GitLab from scratch and told users to reset every password on it. The project says attempts on October 20 and 21, 2026, targeted CVE-2026-97229, the maximum-severity flaw in GitLab’s CI path. Alpine could not prove the attempts stopped short of code execution. The records that would have settled that question were already gone.

That GitLab is the development host for aports, the recipes Alpine uses to build the packages inside a large share of the world’s container images. A quiet change there would travel further than a defaced wiki. Alpine says it found no tampering in repository commits, packages, or releases through October 27, and that package signing keys are kept off that server. The rebuild is the admission that a clean inspection still left the case open.

The version number was ahead of the fix

Alpine had been running GitLab 19.3.4. The fixed build on that branch was 19.3.5. A later move to 19.3.6 still left the hole open on the image Alpine actually ran. The correction depended on a Ruby update that GitLab ships inside its own packages. Alpine’s custom container did not include that Ruby build. The image the project published on October 27, alpinelinux/gitlab:19.3.6, is the one it says carries Ruby 3.3.13 and addresses the CVE.

The attempts showed up as crashes in GitLab worker processes. Alpine counted eight. Four progressed further than a crash that died at once. The project says none of them left proof that code ran. It also says it has no outbound connection record that would let anyone else prove the negative. Alpine’s public reason for the rebuild is that gap: code execution could not be ruled out, and the evidence required to rule it out no longer existed.

The project also found that the actors had retrieved Alpine’s GitLab container image. That is the image whose Ruby build lagged the version printed on the GitLab package. Anyone else running that image inherited the same miss.

If code had run, Alpine’s list of what would have been in reach is user details, password hashes, two-factor secrets, CI secrets, integration credentials, and private project content. The project has not confirmed that any of those left.

What to do with the image and with the account

Replace a running copy of Alpine’s GitLab image with the October 27 publication, and check the Ruby build inside the container. A GitLab version string of 19.3.6 can still be the vulnerable image. The interpreter version is the check that matches the mistake Alpine already made.

Reset passwords on that instance, which is what Alpine has asked its users to do. If the host was reachable while the Ruby fix was absent, rotate CI variables and integration credentials, and review which accounts still have a session and a second factor. Treat missing crash logs and missing egress records as a reason to rebuild, which is the choice Alpine made in public.

Teams that consume Alpine packages, rather than Alpine’s GitLab, have a narrower job. Read the project’s statement that commits, packages, and releases through October 27 showed no tampering, and that signing keys do not live on that server. Keep verifying signatures the way you already should. The next distribution that repackages GitLab will have the same failure mode: a version bump that never carried the language runtime the vendor actually patched.

This briefing relies on public reporting by BleepingComputer, including Alpine Linux’s account of the rebuild.