Alpine Upgraded GitLab Twice and Was Still Exposed, Because the Fix Lived in Ruby

Most patch failures are failures to patch. Alpine Linux's brush with a maximum-severity GitLab flaw is more instructive than that, because the project patched twice and was still exposed both times. The first upgrade landed on the wrong point release. The second landed on the right GitLab version but not on the component the fix actually lived in. In between, an attacker registered an account and spent two days trying to turn a crafted pipeline configuration into code execution on the server that hosts Alpine's source code.

A Week After the Fix, an Attacker Opened an Account

GitLab released fixes for CVE-2026-97229 on October 12 in versions 19.4.2, 19.3.5 and 19.2.8. BleepingComputer describes it as an integer overflow in the CI/CD regular expression compiler, which parses and evaluates the regular expressions in pipeline configuration files, and says it was reported through GitLab's bug bounty program. GitLab's advisory warns that under certain conditions it could have let an unauthenticated user run arbitrary code on the GitLab server.

According to Alpine's own incident report, the project upgraded on October 13 but mistakenly moved to 19.3.4 rather than 19.3.5. On October 20 an attacker registered an account and started probing. The main attack came on October 21, when GitLab began returning 502 errors and CI jobs failed. The attacker crashed GitLab worker processes eight times, and in four of those crashes got partway through the exploit before failing at the next step. The attacker had also downloaded Alpine's GitLab container image, which suggests the exploit was being tuned to that exact build.

The Second Upgrade Did Not Fix It Either

On October 22 Alpine upgraded again, to GitLab 19.3.6. That did not close the hole. The bug sits in Onigmo, the regular expression engine built into Ruby, and GitLab shipped its fix as patches to the Ruby it bundles in its own packages and images. Alpine's image ran on the distribution's standard Ruby, so a newer GitLab version number did not bring the fixed engine with it. Upstream Ruby did not release its own fix until October 23, in versions 3.3.13, 3.4.12 and 4.0.9.

Alpine blocked the attacker's account on October 23. The attacker came back on October 25 and 26 and tried to regain access, and failed. On October 26 the team found the instance was still vulnerable despite the upgrade. It closed GitLab to everyone except developers and build servers on October 27, rebuilt it from scratch, reset every password, replaced GitLab's secret keys, and reopened on 19.3.7 on October 29.

Alpine found no evidence that the attacker's code ran. It is also honest that it cannot rule it out. A successful exploit would leave no crash and no trace in web logs, some logs from the attack day are gone, and outbound connections from the host were not logged. Had the attack worked, the exposed material would have included CI/CD variables, runner tokens, 2FA secrets, webhook and mirror credentials and private repositories. The keys that sign Alpine packages and releases have never been stored on the GitLab server, and the project verified its October 21 stable releases and the packages built from October 20 to 24 against outside records.

“We strongly recommend that all self-managed GitLab installations be upgraded to one of these versions immediately.”

GitLab security advisory, as quoted by BleepingComputer

More Than 1,000 Servers Are Still Open

CISA added CVE-2026-97229 to its Known Exploited Vulnerabilities catalog on October 29 and gave federal agencies until that Sunday to secure their servers under Binding Operational Directive 26-04. SecurityWeek notes that federal agencies had three days to patch. Private organisations are not bound by the directive, and the exposure numbers show it. In an update reported on November 2, Shadowserver said it was tracking more than 1,000 GitLab instances still vulnerable to the flaw. The same report says over 11,300 instances remain vulnerable to CVE-2026-110264, an earlier maximum-severity bug in the same regular expression compiler, out of roughly 39,000 GitLab instances Shadowserver sees each day.

Those are the servers that hold source code, pipeline secrets and deployment credentials for the organisations that run them, and GitLab says its platform is used by more than half of the Fortune 100. Alpine's case shows why the count may understate the risk. Version scanners and patch dashboards read the GitLab version number. Any team that runs GitLab on its own Ruby, from source or in a custom container, can show a fixed version and still be running the vulnerable engine. Alpine's advice is blunt: in that setup, upgrading GitLab alone is not enough.

What Platform and Security Teams Should Do Now

• Verify the fix, not the version string. For self-managed GitLab, confirm you are on 19.4.2, 19.3.5, 19.2.8 or later, and if you supply your own Ruby, confirm it is 3.3.13, 3.4.12, 4.0.9 or newer.
• Inventory what your build images actually bundle. A vendor fix delivered as a patch to a bundled runtime does not travel with a version bump on a rebuilt image, so record which runtime each image really uses.
• Treat self-registration as attack surface. Alpine's attacker needed only a new account to submit crafted CI configuration, so restrict who can sign up and run pipelines on internet-facing instances.
• Log outbound traffic from build infrastructure. Alpine cannot rule out code execution partly because outbound connections were not logged, and it is now adding that logging and keeping logs longer than 14 days.
• Keep signing keys off the code host. Alpine could vouch for its releases because its signing keys never lived on GitLab, and it now plans to sign release tags so they can be verified independently of the server.
• Set a one-day clock for critical releases. Alpine has committed to applying critical GitLab security releases within a day, and to checking each one for Ruby or other component patches its build must apply.

Alpine did most things right once it knew, and its account is unusually candid about the two mistakes that left it exposed. Both came from trusting a label: the version that was installed instead of the one intended, and the version number that changed while the vulnerable code underneath stayed the same. For any team running its own code platform, the lesson is to check that the fix has actually reached the code that runs.