Glonce

Alpine Linux rebuilds GitLab after attempted CVE-2026-97229 exploit

securityThe Glonce editorsHacker News🔥71Glonce rating71Impact60Novelty50Relevance70Surprise60Players25Credibility85

Alpine Linux has published an account of an attack on its GitLab server. On October 20 and 21, an attacker tried to exploit CVE-2026-97229 on the instance, a week after the fix was released. Alpine says the attack came close to working. It has found no evidence that it succeeded, but cannot rule it out, so it treated the instance as compromised and rebuilt it from scratch. Its checks show that the aports repository, packages and the October 21 releases were not tampered with.

The vulnerability is rated critical (CVSS 10.0) and sits in how GitLab evaluates regular expressions in CI configuration. The underlying bug is in Onigmo, the regular expression engine built into Ruby. GitLab published fixed releases on October 12, but the fix is a set of patches to the Ruby that GitLab bundles in its own packages and container images, not a change in GitLab's own code. Upstream Ruby shipped the fix on October 23, in Ruby 3.3.13, 3.4.12 and 4.0.9.

The attack came from a newly registered account that sent crafted CI configurations to the instance, which was still running GitLab 19.3.4 without the October 12 fix. The configurations crashed GitLab worker processes 8 times. In 4 of those crashes the attacker got partway through the exploit and failed at the next step. The attacker also downloaded Alpine's GitLab container image, which Alpine says suggests they were tuning the exploit to its exact build.

Alpine's own upgrade did not help. Moving to GitLab 19.3.6 on October 22 left the instance vulnerable, because Alpine's image used standard Ruby and so never received GitLab's Ruby patch. The instance stayed vulnerable until Alpine closed it on October 27.

What Alpine found: the October 21 stable releases (3.21.9, 3.22.7, 3.23.7, 3.24.3), including their ISO images and the minirootfs tarballs used to build the official Docker images, and all packages built from October 20 to 24 came from aports commits verified against records outside GitLab. Every aports commit added October 20 to 22 arrived through a recorded push by a known developer, checked against a developer's clone and all 45 builders, which the attacker could not reach. Every package built from October 20 to 24, on every architecture, came from commits as published on git.alpinelinux.org. No signing keys were exposed, because the keys that sign Alpine packages and releases are not, and never have been, stored on the GitLab server. Timing probes showed no delays, and Alpine found no unexpected files, keys, hooks or processes. No private data was returned to the attacker through any web or API request Alpine can see.

Why Alpine cannot be sure: a successful exploit would leave no crash and no trace in the web logs. Some logs from the attack day are gone, including background job logs and the old container's filesystem. Alpine had no logging of outbound network connections, and its hosting provider keeps none either. Had the attack succeeded, exposed data could have included email addresses, names and IP addresses of all users, password hashes, 2FA secrets, CI/CD variables and runner tokens, webhook, integration and push mirror credentials, personal access tokens (stored as hashes), and private repositories with confidential issues and merge requests.

The verification checks were run on October 24 and cover commits from October 20 to 22 and packages built up to that date. Because GitLab stayed vulnerable until October 27, Alpine is extending the same checks to that date.

GitLab is being tested before it reopens to the public. All passwords have been reset, so users will need to set a new one through "Forgot your password?" on the sign-in page, and Alpine says it will post exactly what to do at reopening. Alpine has also seen automated login attempts against its GitLab using passwords leaked from other sites, and asks anyone who reused their gitlab.alpinelinux.org password elsewhere to change it there. While GitLab is closed, package mirrors, cgit and mailing lists/IRC are available as normal.

The bug is in Ruby's regular expression engine, so any program that compiles regular expressions from untrusted input is exposed, not only GitLab. Alpine 3.22, 3.23, 3.24 and edge ship Ruby 3.4.12, and Alpine 3.21 ships Ruby 3.3.13; both include the fix, and apk upgrade fetches it.

Alpine plans four changes: the rebuilt instance runs a Ruby with the fix; critical GitLab security releases will be applied within a day, with each release checked for Ruby or other component patches Alpine's own build must apply; outbound connections from the GitLab host and database connections will be logged, and logs kept longer than 14 days; and releases will get signed tags so they can be verified independently of GitLab.

Key facts

  • An attacker used a newly registered account to send crafted CI configurations to Alpine's GitLab on October 20 and 21; they crashed worker processes 8 times, and in 4 of those the attacker got partway through the exploit before failing at the next step.
  • CVE-2026-97229 is rated CVSS 10.0. The bug is in Onigmo, Ruby's regex engine, and GitLab's October 12 fix is a Ruby patch applied only in GitLab's own packages and images, so Alpine's standard-Ruby image stayed vulnerable even after upgrading to GitLab 19.3.6.
  • Alpine found no evidence of success but could not rule it out, so it rebuilt the instance from scratch and reset all passwords.
  • Alpine says aports, packages and the October 21 releases (3.21.9, 3.22.7, 3.23.7, 3.24.3) were not tampered with, and that signing keys were never stored on the GitLab server.
  • Anyone running GitLab with their own Ruby needs Ruby 3.3.13, 3.4.12, 4.0.9 or later in addition to upgrading GitLab.

Why it matters

A maximum-severity (CVSS 10.0) flaw was exploited against a major open source project's own infrastructure, and the attacker nearly got through. The twist is the patching trap: GitLab's October 12 fix lives in a patched Ruby bundled in GitLab's official packages and images, not in GitLab's code, so Alpine's upgrade to 19.3.6 on October 22 did not close the hole. Upstream Ruby only shipped the fix on October 23. Because the bug is in Ruby's regex engine, Alpine notes that any program compiling regular expressions from untrusted input is exposed, not only GitLab.

Who it affects

Anyone who runs GitLab with their own Ruby, whether built from source or in a custom container image, because upgrading GitLab alone does not fix it. Users of the alpinelinux/gitlab image are affected if they pulled a 19.3.6 image before October 27 or use any older tag. Holders of a gitlab.alpinelinux.org account are affected by the password reset and by the credential-stuffing attempts Alpine has seen. Alpine users in general are told their packages and releases were not tampered with.

How to use it

If you run GitLab with your own Ruby, move to Ruby 3.3.13, 3.4.12, 4.0.9 or later as well as upgrading GitLab. If you use the alpinelinux/gitlab image, pull alpinelinux/gitlab:19.3.6 again; the image published on October 27 contains Ruby 3.3.13. On Alpine systems, run apk upgrade to get Ruby 3.4.12 (Alpine 3.22, 3.23, 3.24 and edge) or 3.3.13 (Alpine 3.21). If you have a gitlab.alpinelinux.org account, set a new password with "Forgot your password?" once GitLab reopens, and change the password anywhere else you reused it. Alpine will post instructions when it reopens.

How solid is it

This is a first-party statement from the Alpine Linux infrastructure team, with specific counts, dates, version numbers and a described verification method. The tampering checks compared aports commits and builds against records the attacker could not reach: a developer's clone and all 45 builders. The attacker's tuning of the exploit to Alpine's exact build is Alpine's inference from the image download. The post names no GitLab or Ruby project statement.

Risks and caveats

Alpine cannot prove the exploit failed: a successful run would leave no crash or web-log trace, some logs from the attack day are gone, and neither Alpine nor its hosting provider logged outbound connections. The list of data that could have been exposed (user emails, names and IPs, password hashes, 2FA secrets, CI/CD variables, runner tokens, private repositories and more) is hypothetical, not a report of a confirmed leak. The integrity checks ran on October 24, while GitLab stayed vulnerable until October 27, so Alpine is extending them to that date. The post gives no reopening date for the public GitLab.

“We have found no evidence that it succeeded, but we cannot rule it out, so we treated the instance as compromised and rebuilt it from scratch.”

— Alpine Linux, incident post