Alpine's GitLab Upgrade Left a Critical Ruby Flaw Unpatched
By AgentRiot Editorial
Alpine rebuilt its GitLab server after an attempted exploit left it unable to rule out a compromise. Its custom image needed a Ruby patch that upgrading GitLab alone did not supply.
Alpine Linux says its October 22 GitLab upgrade left a critical vulnerability unpatched after an attacker targeted its development server. The missing fix was in Ruby, not GitLab's application code, and Alpine's custom container image did not receive the patched runtime bundled with GitLab's official packages.
The project has now rebuilt the server and reopened it. Its October 28 incident report, updated October 30 (opens in new tab), says investigators found no evidence of successful attacker code execution or tampering with the packages and releases they checked. Missing evidence prevented them from ruling out a compromise, so they treated the instance as compromised anyway.
The attack arrived after a patch was available
The flaw, CVE-2026-97229, is an integer overflow in regular-expression compilation used by GitLab's CI/CD configuration handling. GitLab rates it CVSS 3.1 10.0, with potential unauthenticated remote code execution. Its October 12 critical patch release (opens in new tab) supplied fixes in 19.2.8, 19.3.5 and 19.4.2 for the corresponding release branches.
Alpine's timeline records an initial mistake: on October 13 it upgraded to 19.3.4, rather than the fixed 19.3.5. An attacker registered an account on October 20 and submitted crafted CI configurations on October 20 and 21. The fact that this attacker used an account does not change GitLab's assessment that the flaw can be exploited without authentication.
According to Alpine, the attempts crashed worker processes eight times. In four crashes, the attacker progressed partway through the exploit before failing at the next step. The attacker also downloaded Alpine's GitLab container image, which the project says suggests an effort to tune the exploit to its build.
CISA added the vulnerability to its Known Exploited Vulnerabilities catalog on October 29 (opens in new tab). That establishes exploitation in the wild; it does not establish that this particular attacker successfully executed code on Alpine's server.
The second upgrade missed the runtime
Alpine upgraded to GitLab 19.3.6 on October 22. That still did not close the hole.
GitLab had addressed the underlying problem by patching the Ruby interpreter shipped in its official packages and container images. Alpine's image used standard Ruby instead. Updating the GitLab application therefore left its regular-expression engine, Onigmo, vulnerable. Alpine discovered the remaining exposure on October 26 and closed GitLab to everyone except developers and build servers on October 27 while rebuilding it.
The Ruby project's October 23 advisory (opens in new tab) confirms that specially crafted patterns could corrupt memory during compilation. It recommends Ruby 3.3.13, 3.4.12 or 4.0.9, or later patched releases, to obtain the full set of related fixes.
There is a branch-specific distinction: Ruby's table lists 4.0.8 as containing the integer-overflow fix associated with CVE-2026-97229. 4.0.9 includes that fix and the other related fixes covered by the advisory.
These bugs affect applications that compile attacker-controlled regular expressions, not those using only developer-written patterns. Ruby says neither a regular-expression timeout nor a pattern-length limit reliably protects against them.
The same container tag had vulnerable and patched images
Alpine's report gives users of alpinelinux/gitlab:19.3.6 a further instruction: pull that tag again.
The image published on October 27 contains Ruby 3.3.13. Alpine says images pulled under the same tag before October 27, and all older tags, are vulnerable. The tag alone therefore cannot distinguish a fixed local image from an earlier vulnerable one.
The rebuilt development server runs GitLab 19.3.7 with Ruby 3.3.13, according to Alpine's October 30 reopening notice (opens in new tab).
No detected tampering, but an incomplete execution record
Alpine says its package and release signing keys have never been stored on the GitLab server. It checked aports commits against records outside GitLab, including a developer's clone and all 45 builders.
The report describes checks covering commits added from October 20 to 22, packages built from October 20 to 24 across architectures, and the October 21 stable releases. Those checks found no sign of tampering. Because GitLab remained vulnerable until October 27, Alpine says it is extending the checks through that date. The completed checks should not be mistaken for a finished audit of the entire exposure period.
Investigators also found no unexpected files, keys, hooks or processes, and no visible web or API request returning private data to the attacker. But successful exploitation could leave no crash or web-log trace. Some background-job logs and the old container filesystem were gone, and neither Alpine nor its hosting provider had outbound-connection logs.
That gap explains the rebuild. Potential exposure of account information, CI/CD variables and integration credentials is part of Alpine's risk assessment, not a confirmed list of stolen data.
Reopening comes with recovery work
Alpine rebuilt the server, replaced GitLab's secret keys and reset passwords, two-factor authentication and tokens. Its recovery instructions (opens in new tab) tell password users to reset their passwords and everyone to set up two-factor authentication again. Anyone who reused their old Alpine GitLab password elsewhere should change it there too. Existing GitHub, GitLab.com and postmarketOS sign-ins still work. Previously created personal access tokens need replacing.
Project maintainers must re-enter CI/CD and pipeline-schedule variable values. The variable names and settings remain, but their values are empty. Alpine advises treating old values as potentially exposed and using new credentials where possible. Webhooks and push mirrors should still work, but their secrets should be replaced. Integration tokens and passwords must be entered again, and OAuth application owners must renew their application secrets.
The server has new SSH host keys. Users should verify their fingerprints against Alpine's published notice rather than dismissing the changed-host warning without checking. Uploaded user SSH and GPG keys were retained.
Alpine says it will apply critical GitLab fixes within a day, check releases for dependency patches its own build must carry, improve logging and introduce signed release tags.