Alpine Linux disclosed on October 28 that it had rebuilt its GitLab server after attempted exploitation of CVE-2026-97229. An application upgrade had left the vulnerable Ruby runtime in place. The project found no evidence of successful code execution, but missing logs meant it could not rule that out, according to its incident report.
Alpine says its checks found no tampering in the packages and releases examined. Those checks had a defined cutoff, however, and the server remained vulnerable beyond it. For administrators running their own GitLab containers, the incident exposes a practical gap: a fixed application version can still sit on an unpatched runtime.
Why the upgrade left Alpine exposed
GitLab released fixes on October 12 in versions 19.4.2, 19.3.5 and 19.2.8. Its advisory rates CVE-2026-97229 at CVSS 10.0 and says a crafted regular expression in CI/CD configuration could allow an unauthenticated attacker to execute code on the server.
Alpine's timeline records two patching failures. On October 13, the team mistakenly installed 19.3.4 instead of the fixed 19.3.5. An attacker then submitted crafted CI configurations on October 20 and 21, crashing worker processes eight times. Alpine says four crashes showed the exploit progressing partway before failing at a subsequent step.
The October 22 upgrade to GitLab 19.3.6 still left Alpine vulnerable. GitLab's fix included patches to the Ruby runtime bundled in its official packages and container images. Alpine's own image used standard Ruby and therefore missed those patches, the project explains.
Ruby's October 23 advisory confirms that GitLab had patched its bundled runtime. Ruby 4.0.9, 3.4.12 and 3.3.13 contain all the fixes discussed in that advisory. For a custom deployment, checking the GitLab version alone cannot establish whether the Ruby process executing it has the relevant fix.
What the integrity checks establish
Alpine checked repository commits against a developer's clone and all 45 builders, using records outside the affected GitLab instance. It says packages built from October 20 through 24 came from verified commits, as did the October 21 releases. Package and release signing keys were never stored on the GitLab server.
That evidence has limits. The checks covered commits from October 20 through 22 and packages built through October 24; GitLab remained vulnerable until it was closed on October 27. Alpine said it was extending verification through that date. It also lacked outbound connection logs, while some attack-day records and the old container filesystem were gone. A successful exploit could have left neither a crash nor a web-log trace, the report warns.
Check the image as well as the tag
Users of Alpine's GitLab image should pull alpinelinux/gitlab:19.3.6 again, according to the incident notice. The image published on October 27 includes Ruby 3.3.13. An earlier pull of that same tag, or any older tag, remains vulnerable. The tag alone therefore does not distinguish the corrected image from its predecessor.
Alpine reset all GitLab passwords and replaced the instance's secret keys during the rebuild. Its October 28 report said testing was underway before public access resumed. Anyone who reused their Alpine GitLab password elsewhere should change it there, the project advises. This reporting is based on the published advisories; we did not test the exploit or inspect Alpine's systems.
The next substantive update is Alpine's extended integrity check through October 27, alongside its reopening instructions. Its report commits to faster critical patching and longer log retention. The outstanding question is whether the additional verification changes the project's account of what the attacker reached.