GitLab CVE-2026-97229: now listed as exploited by CISA, and Alpine Linux shows that upgrading is not always enough

CISA has added CVE-2026-97229, a GitLab flaw rated CVSS 10.0, to its catalogue of exploited vulnerabilities. Alpine Linux reports an attempted attack on its own server, which remained vulnerable after an upgrade because the fix also depends on the Ruby version in use.

What happened

On 29 October 2026, CISA added CVE-2026-97229 to its catalogue of exploited vulnerabilities, giving US federal agencies until 1 November to act and requiring a forensic triage. GitLab rates the flaw critical, with a CVSS score of 10.0: an integer overflow in the compiler for regular expressions used in CI/CD configuration lets an unauthenticated user, under certain conditions, run code on the server. GitLab fixed it on 12 October in 19.4.2, 19.3.5 and 19.2.8. Alpine Linux said on 28 October that an attacker had tried to exploit it on the project’s own GitLab server on 20 and 21 October.

Who is affected and how attackers get in

Self-managed Community and Enterprise editions from 19.2 are affected; GitLab.com and Dedicated are already patched. The bug lies in Onigmo, the regular expression engine built into Ruby, and GitLab’s fix patches the Ruby shipped in its official packages and images. Alpine first installed 19.3.4 by mistake, then 19.3.6 in an image built on standard Ruby, which did not contain the fix. Using a new account and crafted CI configurations, the attacker crashed GitLab workers eight times. Alpine found no evidence of code execution but could not rule it out, so it rebuilt the server from scratch, reset all passwords and replaced GitLab’s secret keys. It says its releases and packages were verified as unmodified and that signing keys were never stored on that server.

What to do now

1. Check your version with sudo gitlab-rake gitlab:env:info.
2. Upgrade to the latest patch of your branch: 19.5.3, 19.4.5, 19.3.7 or 19.2.10.
3. If you build GitLab yourself (from source or in your own container), check ruby -v: you need 3.3.13, 3.4.12, 4.0.9 or later. Pull alpinelinux/gitlab:19.3.6 again if you fetched it before 27 October; older tags are vulnerable.
4. Look for traces: apply the six detection rules published by GitLab and review worker crashes, 502 errors, failed CI jobs and recently registered accounts. A clean result proves little: according to Alpine, a successful exploit leaves no crash and no web-log trace.
5. If in doubt, rebuild and replace secret keys, passwords, CI/CD variables, runner tokens and webhook secrets. Require administrator approval for new accounts.
6. Audit your other Ruby applications: any code passing untrusted input to Regexp.new, Regexp.union or an interpolated pattern needs a patched Ruby. According to the Ruby team, neither Regexp.timeout nor a length limit protects reliably.

Our take

A version number does not prove that a server is patched when the fix sits in a dependency: the check must cover the whole build, especially for custom images. A forge holds source code and deployment secrets, so it should not be left open to anyone on the internet. Keep enough logs, including outbound connections, to answer the question of compromise when it arises.

Sources

• GitLab — Critical Patch Release: 19.4.2, 19.3.5, 19.2.8
• CISA — Known Exploited Vulnerabilities Catalog: CVE-2026-97229
• Alpine Linux — GitLab security incident: attempted exploitation of CVE-2026-97229
• Alpine Linux — GitLab is back: what you need to do
• Ruby — Regexp fixes for GitLab CVEs
• GitLab — Patch Release 19.5.3

How we choose, verify and write our analyses →