Alpine’s GitLab is back. Its rebuild exposes the limits of a version check
A custom Ruby runtime missed a security fix. Contributors now need to restore authentication and pipeline secrets without carrying old access into the rebuilt service.
Alpine Linux's GitLab service is back, but returning contributors have more to restore than a password. The project rebuilt the server and replaced its secret keys after an attempted exploitation of a critical vulnerability. Accounts and project history survived; several mechanisms that let people and automated jobs authenticate did not.
The October 30 reopening instructions describe the remaining work. Passwords and two-factor authentication must be set up again, personal access tokens replaced, and CI/CD variable values re-entered. For maintainers, a repository that loads normally in a browser can therefore still have a broken release pipeline behind it.
An application upgrade missed a component fix
The most revealing detail is in Alpine's incident account. CVE-2026-97229 involved Ruby's regular-expression engine, which GitLab used when processing CI configuration. GitLab's official packages bundled the relevant Ruby patches. Alpine's custom container used a standard Ruby build, so an October 22 GitLab upgrade did not deliver the underlying fix.
That is a concrete example of the difference between an application version and the software actually inside a deployment. A package maintained by the upstream vendor can include component changes that a custom image must incorporate separately. Two installations displaying the same application release need not contain the same patched runtime.
Alpine now reports a rebuilt service running GitLab 19.3.7 with Ruby 3.3.13. Its incident notice also explains that older copies of its 19.3.6 container need particular care: the image was rebuilt with corrected Ruby on October 27. A tag's name alone does not tell an administrator when their local image was obtained.
Restoring access without restoring old secrets
The reset affects several layers. Contributors need a new password and two-factor setup; old recovery codes no longer work. Existing external sign-in through GitHub, GitLab.com or postmarketOS remains available. Personal access tokens used by scripts or Git over HTTPS must be recreated.
For project maintainers, the distinction between a setting and its value matters. CI/CD variables retain their names and configuration, but their values are empty. A deployment job can still find the expected variable and then fail because there is no credential inside it. Alpine recommends using replacement credentials where possible, treating the previous values as potentially exposed.
Webhooks, mirrors and integrations deserve the same attention. A connection that still works is not proof that its secret remained private. This is the operational problem also illustrated by Railway's credential response: service recovery and retiring old access are separate jobs.
The SSH warning should prompt a check
A rebuilt server also has new SSH host keys. Those keys identify the server to a developer's client; they are different from the contributor's own SSH keys, which Alpine retained. The first connection can consequently produce a host-key warning even though the developer's personal key remains valid.
Compare the presented fingerprint with the values in Alpine's reopening notice before accepting the replacement. Automatically dismissing a changed-key warning would discard the very check designed to distinguish an expected rebuild from an unexpected server.
For contributors, the immediate task is to restore the specific credentials and integrations their work uses. For anyone running a custom GitLab image, the broader lesson is more exacting: verify the patched runtime inside the image as well as the application's headline version. The update only reaches the vulnerable component when that component is actually replaced.
