Alpine Linux rebuilt its GitLab server after a close call

Alpine Linux rebuilt its GitLab server after attackers repeatedly tested a maximum-severity vulnerability that could allow unauthenticated remote code execution through a crafted CI/CD configuration. Although maintainers found no proof of a successful break-in, four of eight worker crashes showed the attacker progressing partway through the exploit, and the attacker had downloaded Alpine’s container image to tailor attempts to its build. The server remained vulnerable because Alpine first installed an earlier GitLab release by mistake, then upgraded to a version that still lacked the necessary Ruby regular-expression-engine patch. With crucial logs missing and outbound connections unrecorded, Alpine could not determine whether code had run, so it shut the service down and rebuilt it from scratch. Users were told to replace passwords, two-factor enrollments, tokens, SSH host keys, and CI/CD variables.

The incident shows why updating an application version is not enough when a custom image or bundled runtime also needs a fix. The vulnerability was actively exploited, and more than a thousand unpatched GitLab servers were identified; attacks on developer infrastructure increasingly target pipeline secrets, runner credentials, SSH keys, and AI-assistant data. Alpine plans faster critical updates, checks for patches to underlying components, longer log retention, outbound-connection monitoring, and signed release tags. Administrators should verify that fixes reach every layer, restrict pipeline permissions, rotate all exposed secrets, isolate untrusted builds from trusted systems, and preserve evidence needed to investigate. Strong account security and a recovery plan matter alongside rapid patching, because incomplete logs can leave a full rebuild as the safest option.