A maximum-severity GitLab flaw has moved from patch notes to real-world attacks. CVE-2026-97229 (CVSS 10.0), an integer overflow in how GitLab compiles regular expressions in CI/CD configurations, was used against Alpine Linux’s GitLab instance on October 20 and 21, 2026, just over a week after GitLab’s October 12 fix. CISA added the bug to its Known Exploited Vulnerabilities catalog on October 29 with a November 1 federal deadline and, notably, flagged it as requiring forensic triage under BOD 26-04. And there is a twist for anyone running GitLab on their own Ruby: upgrading GitLab alone may not close the hole. Here’s what happened, who is exposed, and what it means for your self-managed GitLab servers.
The Flaw: A Regex That Breaks the Engine
GitLab lets pipelines match file paths with regular expressions in rules such as rules:exists:regexp and rules:changes:regexp. Rapid7’s analysis shows a crafted pattern that compiles compactly and passes GitLab’s validation, then gets recompiled by Ruby’s Onigmo regex engine when it meets a specially formed UTF-8 file path. An overflow in the program-size math produces corrupted regex instructions, which an attacker can steer into running an operating system command as the GitLab git user.
- Affected versions: GitLab CE and EE 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2.
- Fixed versions: 19.2.8, 19.3.5, and 19.4.2, released October 12.
- GitLab.com and Dedicated: already patched, with no customer action needed, according to Rapid7’s reading of the advisory.
- Root cause: the bug lives in Ruby, so CISA points to Ruby’s October 23 fixes in 3.3.13, 3.4.12, and 4.0.9.
How Attackers Actually Get In
GitLab describes the flaw as exploitable by an unauthenticated user, and the final trigger request needs no login. Rapid7 found one real prerequisite: the attacker must first plant a malicious .gitlab-ci.yml and a crafted file path in a public project. On instances that allow open self-registration and public projects, that hurdle disappears, because anyone can sign up and create one.
That is exactly what happened at Alpine Linux. The attacker used a newly registered account to submit crafted CI configurations, crashing worker processes repeatedly. As Alpine put it, “In 4 of those crashes, the attacker got partway through the exploit and failed at the next step. The attacker also downloaded our GitLab container image, which suggests they were tuning the exploit to our exact build.” Alpine says it found no evidence of code execution but “cannot rule it out,” so it rebuilt the instance from scratch and reset all passwords, and reports its aports repository, packages, and October 21 releases were not tampered with.
The Ruby Catch
Alpine’s instance was still vulnerable after upgrading to GitLab 19.3.6, because its image runs the distribution’s standard Ruby rather than the Ruby bundled in GitLab’s official packages. Alpine’s warning is blunt: “If you run GitLab with your own Ruby (from source or in your own container image) rather than GitLab’s packages, upgrading GitLab is not enough: you also need Ruby 3.3.13, 3.4.12, 4.0.9 or later.”
CISA’s KEV entry makes the same point, noting that other products can be affected by the same underlying regex bug. For IT teams, that means checking any Ruby application that compiles user-supplied regular expressions, not just GitLab.
What to Do Right Now
- Upgrade GitLab: move self-managed CE and EE servers to 19.2.8, 19.3.5, 19.4.2, or later.
- Check your Ruby: on source installs and custom images, confirm Ruby is at 3.3.13, 3.4.12, 4.0.9, or later.
- Lock down sign-ups: disable open registration or require admin approval, and restrict who can create public projects.
- Hunt for crashes: GitLab’s security team has published a detection for native Ruby crashes in Puma worker error logs with Onigmo frames such as onig_compile and compile_tree, a telltale of exploit attempts.
- Assume compromise if exposed: if an unpatched internet-facing instance allowed sign-ups, review new accounts and pipelines, rotate runner tokens, CI variables, and deploy keys, and consider a rebuild as Alpine did.
Looking Ahead
This is the second Onigmo-related GitLab code-execution bug to make headlines this month, and the pattern is clear: anywhere user input reaches a regex engine, attackers are looking. With a public lab exploit already circulating on GitHub and CISA demanding forensic checks, expect scanning of self-managed GitLab servers to intensify through November.
The bigger takeaway is supply chain. Source-code servers hold the keys to builds, secrets, and releases, which is why Alpine’s careful rebuild matters so much. Treat your GitLab instance like the crown-jewel system it is: patched promptly, closed to anonymous sign-ups, and watched for the quiet crashes that signal someone is tuning an exploit.
Sources:
- GitLab Security Release, October 12, 2026
- Rapid7, October 13, 2026
- CISA, October 29, 2026
- SecurityWeek, October 30, 2026
