What happened
Alpine Linux’s October 28 incident report, updated October 30, says an attacker used a newly registered account to send crafted CI configurations to the project’s GitLab instance on October 20 and 21. The server was running GitLab 19.3.4, without the fix released on October 12. The configurations triggered eight crashes of GitLab worker processes. In four crashes, the attacker got partway through the exploit but failed at its next step. The attacker also downloaded Alpine’s GitLab container image, which the project says suggests the attacker was tuning the exploit to that particular build.
The flaw, CVE-2026-97229, has a CVSS score of 10.0. It affects how GitLab evaluates regular expressions in CI configuration; the underlying bug is in Onigmo, the regular-expression engine built into Ruby. GitLab’s October 12 fix consisted of patches to the Ruby version bundled in its own packages and container images. Upstream Ruby shipped the fix on October 23 in Ruby 3.3.13, 3.4.12 and 4.0.9.
Alpine says it upgraded to GitLab 19.3.6 on October 22, but that did not fix the vulnerability in its image: Alpine’s build used standard Ruby rather than GitLab’s patched bundled Ruby. The project found on October 26 that the instance was still vulnerable. It closed GitLab to everyone except developers and build servers on October 27 and began a rebuild. The rebuilt instance had Ruby 3.3.13 or later; Alpine says GitLab reopened on October 29, upgraded to 19.3.7, and its October 30 update confirms it is open again.
Alpine found no evidence that the attacker ran code on the server, returned private data through a web or API request, or modified its repositories and releases. It checked the aports repository, packages, and October 21 stable releases against records outside GitLab, including a developer’s clone and all 45 builders. No package-signing keys were exposed: Alpine says those keys are not stored on the GitLab server. However, logs from the attack day were missing, and the project had no logging of outbound network connections. A successful exploit could leave no crash or web-log trace, so Alpine could not exclude compromise.
The incident report says a successful exploit might have exposed user names, email addresses and IP addresses; password hashes; 2FA secrets; CI/CD variables and runner tokens; credentials for webhooks, integrations and push mirrors; personal access tokens stored as hashes; and private repositories or confidential issues and merge requests. Alpine reset passwords and replaced GitLab secret keys. It advises anyone who reused their GitLab password elsewhere to change it there too. For users of its alpinelinux/gitlab image, the project says to pull 19.3.6 again: the image published October 27 contains Ruby 3.3.13, while any copy of that tag pulled earlier and all older tags remain vulnerable. Operators using their own Ruby need Ruby 3.3.13, 3.4.12, 4.0.9 or later. Alpine also says its Ruby packages in Alpine 3.21 through 3.24 and edge include the fix; apk upgrade installs it.
What the archive adds
A related Ruby release note covered Ruby 4.0.9, 3.4.12 and 3.3.13 and the Onigmo fixes behind GitLab’s vulnerabilities. Alpine’s disclosure is a new incident on that known story: it supplies evidence of attempted exploitation and explains how a custom GitLab image remained vulnerable after a GitLab upgrade.
Trend signal
This supports agent security moves to runtime boundaries: security depends on the executable environment and components actually deployed, not merely the application version an operator believes they upgraded. The incident is about GitLab rather than an agent, so the connection is a broader runtime-security lesson, not direct evidence about agent deployments.
Why now
Alpine says the attack occurred October 20–21, discovered the image remained vulnerable on October 26, and completed a rebuild before reopening GitLab. Its October 30 update provides the current operational status and tells users what to do after service returned.
Why it matters
For teams that build or consume custom application images, this is a reminder to track fixes below the top-level product. GitLab 19.3.6 looked like an upgrade, but Alpine’s image still carried an unpatched Ruby because the fix lived in GitLab’s bundled Ruby packages, not in GitLab’s own code. Operators need to identify which dependency version their artifact contains, rebuild or repull the corrected artifact, and verify the result rather than treating an application version number as proof of remediation.
The incident also demonstrates why incident response must distinguish “no evidence of compromise” from “evidence of no compromise.” Alpine’s checks support its conclusion that packages and releases were not tampered with, but missing logs prevented it from ruling out code execution on the server. Rebuilding, resetting credentials and replacing secrets were costly steps, yet they removed a possible foothold and reduced uncertainty. Teams running source-control infrastructure should know which credentials and release systems depend on that host, and keep independent records that can help establish artifact integrity after an incident.
What happens next
- Alpine will apply critical GitLab security releases within a day and check each release for patches to bundled components. (6 months, 75%). Watch for: a documented response-time policy or incident follow-up describing its application.
- Alpine will add outbound-connection and database-connection logging and retain logs longer than 14 days. (6 months, 70%). Watch for: an operational update confirming the new logging and retention controls.
Limits and uncertainty
This account is Alpine Linux’s own incident disclosure. It reports no evidence of code execution, data access or tampering, but explicitly says it cannot rule out code execution because some logs and the old container filesystem were gone and outbound connections were not logged. The report does not establish that any listed user data was actually accessed or exposed. Its verification of repositories, packages and October 21 releases covered specified commits and build dates; Alpine said it was extending checks through October 27. The supplied material does not include an independent forensic assessment or a complete account of the attacker’s identity or motive.
Skill to build now
This week, audit one production container you maintain: record its application version and the versions of security-sensitive runtime components inside it, then compare them with the vendor’s fix instructions. For a GitLab image, Alpine’s specific guidance is to pull alpinelinux/gitlab:19.3.6 again if the earlier copy predates October 27, or use Ruby 3.3.13, 3.4.12, 4.0.9 or later in a custom build. Make artifact identity and rebuild date part of your patch checklist.
Reader takeaway
A fixed application release does not guarantee a fixed deployment when the vulnerable code is in a separately bundled runtime. Alpine’s report shows both the value and the limits of incident evidence: it verified that packages and releases were intact, but rebuilt GitLab because missing telemetry meant it could not prove the server had not been compromised. Check the actual contents of your image, not just its top-level version.