Alpine Linux Installed a GitLab Fix and Was Still Exploitable: The Patch Also Needed a Ruby Update. How Do You Know a Patched Server Is Actually Patched?

CISA added the maximum-severity GitLab flaw CVE-2026-97229 to its Known Exploited Vulnerabilities catalog on 29 October 2026, and Alpine Linux has now described what that looks like from the inside: attackers tried to exploit its GitLab server nine days after the fix shipped, and an upgrade it believed was sufficient had not closed the hole. According to BleepingComputer's report on Alpine's incident post, Alpine could not rule out code execution, so it rebuilt the server from scratch and reset every password.

The flaw

CVE-2026-97229 is an integer overflow in the regular expression compiler that GitLab's CI/CD uses to evaluate expressions in pipeline configuration files. A remote, unauthenticated attacker can supply a crafted expression and run arbitrary code on the GitLab server. As BleepingComputer reported on the CISA listing, GitLab fixed it in versions 19.4.2, 19.3.5 and 19.2.8, says it has detected exploitation attempts, and has released detections for self-managed customers. Shadowserver tracks nearly 2,800 internet-exposed GitLab Community Edition instances.

It is the latest in a run of GitLab problems. We covered a critical flaw in the GitLab AI Gateway earlier this month, and the same BleepingComputer report notes a separate maximum-severity regular expression compiler bug (CVE-2026-110264) fixed in October, plus a path traversal bug (CVE-2026-85706) that can expose credentials and secrets and is also on the KEV list.

What went wrong at Alpine

Alpine's account is useful because it is specific about how a careful team ended up exposed.

• 12 October: GitLab disclosed the flaw and released fixes.
• Wrong point release: Alpine first installed 19.3.4 rather than the patched 19.3.5.
• Right version, still vulnerable: its later move to 19.3.6 did not close the flaw either. The underlying bug sits in Onigmo, the regular expression library bundled with Ruby, so the fix also required a patched Ruby. Alpine's custom container image did not include one.
• 20 to 21 October: attackers submitted malicious CI configurations containing crafted regular expressions. The attempts crashed eight workers, four of them partially successful, though none appeared to fully succeed.
• Image download: the attackers also pulled Alpine's GitLab container image, which Alpine says may indicate preparation for a supply-chain attack.

Alpine found no tampering in commits, packages or releases up to 27 October, and says its signing keys are not stored on the GitLab server. But logs were missing and there were no outbound connection records, so it could not rule out code execution. Data that may have been exposed, with no compromise confirmed, includes user details and password hashes, 2FA secrets, CI/CD secrets and integration credentials, and private project content. The fixed image, alpinelinux/gitlab:19.3.6, was published on 27 October and includes Ruby 3.3.13.

The lesson: a version number is not a patch status

The common check, "are we on or above the fixed release?", would have given Alpine a wrong answer twice. Three practical points follow.

1. Track the runtime, not just the application. When a fix lands in a bundled library or language runtime, your inventory needs to record that component's version too, especially for custom container images.
2. Know which instances are public. Self-hosted GitLab holds source code, signing workflows and deployment credentials. An instance that was meant to be internal but answers on the internet is the one attackers find first.
3. Treat missing logs as a finding. Alpine's inability to rule out compromise came down to absent logs and connection records. Decide before an incident which servers must keep outbound connection logs.

If you ran a vulnerable GitLab between disclosure and a full fix, the conservative response is Alpine's: rotate CI/CD secrets and integration credentials, reset passwords and 2FA secrets, and review pipeline configurations for unexpected regular expressions.

How Obiguard Scout fits

Before you can verify a patch, you have to know the server exists. Obiguard Scout is our external attack surface product: it maps the hosts your organisation exposes to the internet, including developer tooling such as GitLab, CI runners and package registries that teams often stand up outside the normal asset process, and it records the software and versions it observes. For a flaw like CVE-2026-97229, that gives you the list of public GitLab hosts to check first, and a baseline to compare against when a second advisory follows the first. Scout sees what is visible from outside; confirming the runtime inside a container image still needs your own build records. You can start with a free Scout check on any domain you own to see which hosts are already published under it.

Sources

• BleepingComputer: CISA says max severity GitLab flaw now exploited in the wild
• BleepingComputer: Alpine Linux rebuilds GitLab after attempted RCE attack