GitLab vulnerability survived upgrade on Alpine server
The GitLab vulnerability CVE-2026-97229 remained exploitable on Alpine Linux’s self-hosted server even after GitLab was upgraded, because the project’s container used a separate Ruby installation that did not receive GitLab’s bundled patch. Alpine said an attacker submitted crafted continuous integration, or CI, configurations on 20 and 21 October. It found no proof that code ran, but missing evidence meant it could not exclude a successful compromise.
CVE-2026-97229 has a Common Vulnerability Scoring System, or CVSS, rating of 10.0, the highest score on that severity scale. Under certain conditions, a malicious regular expression, a text-searching pattern, in a CI configuration can make GitLab run attacker-controlled code. The underlying defect is in Onigmo, the regular expression engine included with Ruby. GitLab uses Ruby to process expressions found in CI files.
GitLab released its initial fix on 12 October by modifying the Ruby bundled with its own Linux packages and official container images. Alpine upgraded its server to GitLab 19.3.4 on 13 October rather than 19.3.5, which Alpine described as a mistake. A newly registered account began probing the still-vulnerable server on 20 October. The submitted configurations crashed GitLab worker processes eight times over two days. The main attempt on 21 October also produced 502 errors and interrupted CI jobs. Alpine said four crashes showed that the exploit had reached an intermediate stage before failing. The account also downloaded Alpine’s GitLab container image, which suggested the attacker was adapting the attempt to that specific build.
Alpine blocked the account on 23 October. Attempts to return on 25 and 26 October failed. However, the project discovered on 26 October that its upgrade to GitLab 19.3.6 on 22 October had not closed the flaw. The alpinelinux/gitlab image installed standard Ruby separately, so it did not contain the patched Ruby shipped in GitLab’s own packages and images. Alpine restricted the service to developers and build servers on 27 October, then rebuilt it from the ground up. The rebuild finished on 28 October with Ruby 3.3.13 or later, replaced GitLab secret keys and mandatory password resets. Alpine was testing the rebuilt service before reopening it publicly.
Alpine found no unexpected files, processes, hooks or credentials, and timing tests did not show the delays expected from its probes. It also found no visible web or application programming interface, or API, request sending private information to the attacker. Those checks were not conclusive. Alpine said a successful attempt might produce neither a crash nor a web-log trace. Some background-job logs and the previous container filesystem were unavailable, while neither Alpine nor its hosting provider had recorded outbound connections. It therefore treated the server as compromised rather than assuming the absence of evidence meant the attack failed.
If code execution occurred, exposed material could have included user names, email and IP addresses, password hashes, two-factor authentication secrets, CI/CD variables, runner tokens, integration and webhook credentials, private repositories, confidential issues and merge requests. Personal access tokens were stored as hashes. Alpine has not said whether it replaced runner tokens, CI/CD variables, access tokens or integration credentials beyond resetting passwords and changing GitLab’s secret keys.
The affected server hosts aports, the repository used to build Alpine packages. Alpine verified every aports change added from 20 through 22 October against a developer’s repository copy and all 45 build servers, records it said the attacker could not access. It confirmed that each change arrived through a recorded push from a known developer and that packages produced from 20 through 24 October matched the aports history published on git.alpinelinux.org. Checks were being extended through 27 October. The reviewed releases included the minirootfs files used for official Alpine Docker images. Package and release signing keys had never been stored on the GitLab server.
Administrators need to distinguish GitLab’s official packages from installations that supply their own Ruby. GitLab’s Linux package and official container images should be moved to the newest release for their branch. The 21 October releases were 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 and 18.11.13. GitLab lists 19.4.2, 19.3.5 and 19.2.8 as versions fixing CVE-2026-97229 on their respective affected branches. The advisory originally identified 19.3.4 as fixed but now marks it affected, so installations still using 19.3.4 should move to 19.3.6. The newer releases also address CVE-2026-110264, a separate regular expression flaw.
Self-compiled installations and custom images that install Ruby independently must update both components. Fixed Ruby releases are 3.3.13, 3.4.12 and 4.0.9 or later. Ruby 3.2 reached end of life in April and will not receive this correction, although GitLab’s self-compiled installation guide still listed it as the minimum as of 29 October. GitLab’s 12 and 21 October patch posts did not tell self-compiled administrators to update Ruby. Alpine users should pull alpinelinux/gitlab:19.3.6 again because the image published on 27 October contains Ruby 3.3.13, while earlier copies of that tag and every older tag remain vulnerable. Alpine’s Ruby packages contain 3.4.12 on Alpine 3.22, 3.23, 3.24 and edge, and 3.3.13 on Alpine 3.21; running apk upgrade installs them.
Rapid7 produced a working laboratory exploit and released proof-of-concept code on 13 October. It ran commands as GitLab’s git user on an unpatched official GitLab 19.4.1 image but failed against 19.4.2. Its route requires a malicious .gitlab-ci.yml file and a path containing UTF-8 characters to be committed to a public project before the final unauthenticated CI lint request. That barrier may not apply where anyone can register and create projects. Rapid7 does not know how the still-private original report avoids the write step, and Alpine has not explained how the attacker delivered its configurations. CVE-2026-97229 was not in CISA’s Known Exploited Vulnerabilities catalog as of its 28 October update.
GitLab has issued six Sigma detection rules for self-managed servers, four marked experimental. They look for suspicious CI warnings, GraphQL ciLint requests, unusually long non-ASCII paths and Ruby crash reports involving Onigmo. Administrators should also inspect temporary files, Puma or Sidekiq child processes, outbound connections, changed scheduled tasks and altered SSH credentials. Evidence of code execution calls for treating the host as compromised and replacing GitLab secrets, CI/CD variables, runner tokens and access tokens. Temporary restrictions on anonymous access, public-project writing or the CI lint route cover only Rapid7’s demonstrated path and do not repair Ruby.