CVE-2026-97229 — a critical GitLab vulnerability rated CVSS 10.0 — was probed against Alpine Linux’s own GitLab server within a week of GitLab issuing a fix, and Alpine responded by rebuilding the service and resetting every account password, the project said on 28 October.
How the attacker’s activity unfolded on alpine’s GitLab
Alpine upgraded its GitLab server to 19.3.4 on 13 October (an upgrade the project called a mistake), and later to 19.3.6 on 22 October. The server remained vulnerable because Alpine’s image used the distribution’s standard Ruby rather than the patched Ruby shipped inside GitLab’s packages and official images.
A newly registered account began probing the server on 20 October. The account submitted crafted CI configurations on 20 and 21 October; those inputs crashed GitLab worker processes eight times, produced 502 errors, and caused CI jobs to fail. In four crashes Alpine says the attacker progressed partway through the exploit and then failed at the next step. Alpine also recorded that the attacker downloaded Alpine’s GitLab container image, which Alpine said "suggests they were tuning the exploit to our exact build."
Alpine blocked the account on 23 October; the attacker returned with failed attempts on 25 and 26 October. On 27 October Alpine closed public access, began rebuilding the server, and completed that rebuild on 28 October. The rebuilt server runs Ruby 3.3.13 or later and uses new GitLab secret keys; Alpine said it is testing the service before reopening it to the public.
Why upgrading GitLab alone did not remove the flaw
The underlying defect is in Onigmo, the regular-expression engine built into Ruby, not in GitLab’s application code. GitLab’s 12 October release remedied the problem by shipping a patched Ruby inside its Linux packages and container images. Ruby maintainers published fixed Ruby versions on 22 and 23 October.
But a GitLab upgrade does not change a server’s system Ruby. Alpine’s image installed or relied on standard Ruby, so moving the GitLab application to 19.3.6 on 22 October did not mitigate CVE-2026-97229. Alpine warned that "upgrading GitLab is not enough" for installs that run their own Ruby builds; those servers require Ruby 3.3.13, 3.4.12, 4.0.9 or later. The advisory also notes Ruby 3.2 reached end of life in April and will get no fix.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildWhat Alpine could and could not verify after the probes
Alpine reported it found no sign that attacker-supplied code executed on the server: there were no timing delays, no unexpected files, keys, hooks, or processes, and Alpine saw no evidence of private data being exfiltrated via web or API requests it can observe. Still, Alpine said it cannot be sure. "A successful exploit would leave no crash and no trace in the web logs," the project wrote.
Some necessary evidence is missing: background job logs and the old container filesystem from the day of the attack are gone, and neither Alpine nor its hosting provider logged outbound network connections. Because the evidence needed to conclusively confirm code execution no longer exists, Alpine treated the server as compromised, rebuilt it from scratch, and replaced secret keys and passwords.
If the attack had succeeded, Alpine listed categories of data that could have been exposed, including email addresses, password hashes, 2FA secrets, CI/CD variables and runner tokens, webhook and integration credentials, personal access token hashes, and private repositories and confidential issues.
Alpine has not said whether it rotated runner tokens, CI/CD variables, access tokens, or integration credentials stored on the server beyond the reset of account passwords and the new secret keys.
Detection, mitigations, and the exploit’s shape
Rapid7 published a working proof-of-concept exploit on 13 October that ran commands as GitLab’s git user in a lab against an unpatched official GitLab 19.4.1 image; the same input did not run on 19.4.2. That exploit requires the attacker first to gain write access to create a malicious .gitlab-ci.yml and a file path with UTF‑8 characters in a public project — a step that may be unnecessary on servers where new users can register and create projects.
GitLab published six Sigma-format detection rules for self-managed servers; four are marked experimental and look for hostile CI regexp warnings, GraphQL ciLint requests, unusually long non-ASCII file paths, and Ruby crash reports pointing to Onigmo. GitLab’s guidance also recommends looking for files owned by the git user in /tmp, unexpected Puma or Sidekiq child processes, outbound connections, and changed crontabs or SSH keys for the git user. If code execution is suspected, GitLab advises treating the server as compromised and rotating secrets in gitlab-secrets.json, all CI/CD variables, runner tokens, and access tokens.
Where an immediate upgrade is not possible, Rapid7 suggests restricting anonymous access to public projects, preventing untrusted users from creating or writing to public projects, or blocking the CI lint route — measures that cover Rapid7’s exploit path but do not fix the vulnerable regular-expression compiler itself.
What this means for GitLab administrators, Alpine users, and security teams
- GitLab administrators: Verify whether your installation uses the system Ruby or GitLab’s bundled Ruby. If you run a self-compiled install or a container that installs Ruby separately, update Ruby to 3.3.13, 3.4.12, 4.0.9 or later and apply the newest GitLab release for your branch. Servers still on 19.3.4 should move to 19.3.6.
- Alpine users and package consumers: Alpine confirmed that packages built from 20 to 24 October and the 21 October releases came from aports changes recorded outside GitLab, and that the keys that sign packages were never on the GitLab server. Users of alpinelinux/gitlab should pull alpinelinux/gitlab:19.3.6 again — the 27 October image contains Ruby 3.3.13; any 19.3.6 image pulled before then, and every older tag, is vulnerable. Alpine’s Ruby packages carrying the fix can be installed via apk upgrade.
- Security teams: Logs and outbound-connection records can be decisive. Alpine’s inability to show outbound logging or retain certain logs forced a conservative remediation: a full rebuild and key rotation. Detection rules exist, but Alpine’s case shows that a successful exploit can leave no web-log trace.
Alpine closed its public GitLab, rebuilt the service, and reset passwords; whether any attacker achieved execution remains unknown because the forensic evidence is incomplete. The concrete next step the project and other operators must complete is clear: ensure Ruby is updated where GitLab’s bundled fixes do not apply, and treat installs that run their own Ruby as unchanged by a simple GitLab upgrade.
