Alpine says it rebuilt GitLab after eight worker crashes

Alpine Linux says it completed a server rebuild, reset every account’s password and replaced GitLab’s secret keys on 28 October. Its 22 October upgrade to GitLab 19.3.6 had left a critical flaw open because its server used separately installed Ruby, the project said in a disclosure described by The Hacker News. Alpine found no evidence that the attacker ran code, but could not rule it out.

GitLab released its fix on 12 October. Alpine said it mistakenly upgraded to 19.3.4 rather than the fixed 19.3.5 on 13 October, leaving the server unpatched when attacks began a week later. Its subsequent upgrade still did not supply the Ruby fix included in GitLab’s official packages and container images.

Alpine Linux is a Linux distribution commonly used in containers because of its small size and quick startup. The affected server, gitlab.alpinelinux.org, hosts aports—the repository of changes from which Alpine packages are built.

Why upgrading GitLab was not enough

CVE-2026-97229 concerns regular expressions—patterns used to match text—in continuous integration (CI) configurations, which control automated build and test jobs. GitLab processes those patterns using Ruby. The underlying bug is in Onigmo, Ruby’s built-in pattern-matching engine.

The flaw has a severity score of 10.0 out of 10. GitLab’s advisory says it could allow someone who is not signed in to run code on the server “under certain conditions.”

GitLab fixed the problem by patching the Ruby bundled with its official Linux packages and container images. Alpine’s image installed Ruby separately, so changing the GitLab version did not change that runtime. The same distinction applies to installations built from source or placed in custom images with their own Ruby.

GitLab’s advisory initially named 19.3.4 as fixed, but now lists it as affected and names 19.3.5 as the fixed release. Administrators using GitLab’s official packages or images should install the newest release for their branch. Those using separately installed Ruby must also update Ruby to the fixed version for its branch, or later:

Ruby 3.2 will not receive a fix, so servers using it need to move to a fixed branch. Users of Alpine’s image must download alpinelinux/gitlab:19.3.6 again: the image published on 27 October includes Ruby 3.3.13, but copies downloaded before then and all older image tags remain vulnerable.

What the attacks did—and what remains unconfirmed

Alpine said a newly registered account sent crafted CI configurations on 20 and 21 October, crashing GitLab worker processes eight times. In four crashes, the exploit progressed partway before failing at its next step. The main attack on 21 October also caused server errors and failed CI jobs.

Alpine blocked the account on 23 October and said attempts to return on 25 and 26 October failed. On 26 October, it discovered that the server remained vulnerable despite the upgrade. It restricted access to developers and build servers on 27 October and began rebuilding. The rebuilt server runs fixed Ruby.

Alpine found no unexpected files, keys, hooks or processes, and no private data returned through the web or API requests it could inspect. But a successful exploit could leave neither a crash nor a web-log trace. Some attack-day background-job logs and the old container’s filesystem were gone, while neither Alpine nor its hosting provider recorded outbound network connections. Alpine therefore treated the server as compromised and rebuilt it to remove any foothold an attacker might have left.

If code execution succeeded, Alpine said the attacker could have accessed users' names, email and IP addresses; password hashes; two-factor authentication secrets; private repositories; and confidential issues and merge requests. Automation credentials were also potentially exposed: CI/CD variables used by build and delivery jobs, runner tokens, webhook and integration credentials, push-mirror credentials, and personal access tokens stored as hashes.

Beyond resetting passwords and replacing GitLab’s secret keys, Alpine has not said whether runner tokens, CI/CD variables, access tokens or integration credentials have been replaced.

What Alpine’s package checks cover

Alpine said its checks matched every aports change added from 20 to 22 October to a recorded submission by a known developer. It compared those changes with a developer’s repository copy and records from all 45 build servers—records it said the attacker could not reach.

Every package built from 20 to 24 October, across all architectures, came from the verified changes, Alpine said. The 21 October releases also used those changes, including the minimal root-filesystem archives used to build the official Alpine container images.

Those checks were performed on 24 October, while GitLab remained vulnerable until its closure on 27 October. Alpine is extending the checks through that later date. It also said its package and release signing keys were not exposed because they had never been stored on the GitLab server; those are distinct from the GitLab secret keys replaced during rebuilding.

What users should do before reopening

Alpine advises anyone who reused their gitlab.alpinelinux.org password elsewhere to change it on those other services. It has also seen automated login attempts using passwords leaked from other sites. When GitLab reopens, account holders will need to select “Forgot your password?” on the sign-in page and set a new password.

Alpine’s package mirrors, repository browser, mailing lists and chat services remain available while public GitLab access is closed.

As of 29 October, access remained restricted to Alpine developers and build servers. Alpine was testing the rebuilt server before public reopening and had not announced a reopening date. It said it would publish account-access instructions when the service returns.