Summary
- Attackers attempted to exploit CVE-2026-97229 against Alpine Linux's GitLab instance.
- The project rebuilt the service, replaced credentials, and verified source and package integrity.
- Investigators found no evidence of successful code execution but could not exclude it completely.
Alpine Linux has restored its GitLab development service after rebuilding infrastructure that was targeted through a critical vulnerability. The project says independent checks of its source code and distributed packages found no evidence that an attacker altered published software.
Alpine reopened the service on 29 October and provided further restoration details on 30 October. The rebuilt server was running GitLab 19.3.7 with Ruby 3.3.13, incorporating fixes for CVE-2026-97229, a severe flaw associated with the Ruby regular expression engine used by the code-hosting platform.
The incident began on 20 October, when a newly created account submitted specially crafted continuous integration configurations. The server suffered eight worker-process crashes during 20 and 21 October, including four instances in which the attack appeared to progress partway through the exploit sequence. Those crashes provided evidence of attempts rather than proof of completed remote code execution.
Alpine found no evidence of successful execution on the original GitLab server. However, missing historical records and limitations in its logging meant the project could not definitively exclude compromise. It treated the server as potentially untrusted and rebuilt it instead of relying on patching alone.
The response required replacing GitLab secret keys and resetting user credentials. Developers and maintainers were instructed to configure new passwords, multifactor authentication, and relevant access tokens. Integrations relying on old tokens or server secrets could require reconfiguration before automated jobs and repository access returned to normal.
A complication emerged from the way Alpine assembled its GitLab installation. The project used a Ruby runtime packaged separately from GitLab’s official distribution, so an update to the central application did not initially deliver the corresponding fix to the underlying regular expression component.
GitLab had released security fixes on 12 October. Alpine subsequently found that its own packaging combination retained exposure despite upgrading the main application. The installed software version therefore did not provide a complete picture of the effective security state of the runtime actually processing hostile input.
The problem highlights a practical issue in complex application maintenance. Distributors can provide components individually, apply backported fixes, or rebuild software against other versions of a runtime. Teams need to account for the exact dependency used by a deployed service rather than assuming that one vendor’s release label describes every component.
Because GitLab hosts source code and development workflows, Alpine also needed to determine whether the attempted intrusion affected its software supply chain. A compromised repository platform can offer opportunities to alter commits, build instructions, or release assets, but those outcomes require their own evidence and cannot be inferred from attempted access alone.
Alpine compared repository history against information retained independently of the potentially affected server, including build records. It reported no evidence of alteration to its package repository, distributed binaries, or October releases. Its package-signing keys were held outside the GitLab server, reducing the risk that control of that machine would also enable forged package signatures.
Those independent records were especially important because a potentially compromised system cannot be treated as the sole authority on its own integrity. Retaining evidence outside the environment under investigation provides a basis for checking whether source and output records have been changed.
Rebuilding the development platform restored a trusted operating environment, but account resets also interrupt legitimate workflows. Continuous integration jobs, mirrored repositories, and automated deployment processes may hold tokens that must be replaced. Recovery therefore extends to dependencies that normally operate without direct human intervention.
Alpine has identified further work involving patch handling, connection logging, retention of forensic records, and release verification. Each improvement follows from an aspect of the investigation: the overlooked runtime patch, the limits on confirming whether execution occurred, and the need to establish package integrity independently.
The service is available again and the project reports no tampering with its packages. The remaining uncertainty concerns whether any attempt achieved code execution before the original server was retired, a question that cannot be answered conclusively from the retained logs.
