CVE-2026-97229 is a critical GitLab vulnerability that lets an attacker without an account run code on your GitLab server. A fix has been out since 12 October. If you build GitLab yourself, though, upgrading GitLab will not close it: the bug lives in Ruby, and Ruby needs patching too.
Alpine Linux learned that the hard way, and its write-up is worth ten minutes of any CISO's time if your organisation self-hosts GitLab.
What is the GitLab vulnerability CVE-2026-97229?
GitLab fixed the flaw on 12 October in its critical patch release 19.4.2, 19.3.5 and 19.2.8. It is an integer overflow triggered when GitLab compiles a regular expression supplied in a CI/CD configuration. Under certain conditions, an unauthenticated user can use it to execute arbitrary code on the server, and GitLab rates it CVSS 10.0, the maximum. Community and Enterprise Editions are affected from 19.2 before 19.2.8, 19.3 before 19.3.5 and 19.4 before 19.4.2. GitLab.com and GitLab Dedicated had already been patched by the time the release went out.
The root cause sits one layer down. On 23 October the Ruby project explained that three bugs in Onigmo, Ruby's regular expression engine, sit behind four GitLab CVEs, this one included. GitLab dealt with them in its own releases by patching the Ruby it ships. Upstream Ruby followed the same day with versions 4.0.9, 3.4.12 and 3.3.13, which carry all the fixes.
Your engineers need two things from the Ruby notice. A regex timeout gives no protection against these bugs. Capping pattern length is not a reliable defence either, because some of them can be triggered with short patterns.
How Alpine Linux got caught out
Alpine Linux, a widely used Linux distribution, published a candid incident report on 28 October. On 13 October the team upgraded its own GitLab to 19.3.4, one release short of the fix. On 20 and 21 October a freshly registered account submitted crafted CI configurations aimed at the flaw. The attacker crashed GitLab worker processes eight times and got partway through the exploit in four of those attempts. They also pulled Alpine's own GitLab container image, presumably to tune the exploit to that build.
On 22 October Alpine moved to 19.3.6, which still left the hole open. Their image ran the distribution's standard Ruby, while the fix is a Ruby patch GitLab applies only in its official packages. The attacker came back on 25 and 26 October and failed.
Alpine found no evidence the exploit succeeded. A successful run would leave nothing in the web logs, however, and some logs from the day of the attack were missing. So the team treated the server as compromised. They took GitLab offline, rebuilt it from scratch, reset every password and replaced GitLab's secret keys. Checks of their repository, packages and releases against records held outside GitLab showed no tampering.
A version number is not proof of a patch
On a dashboard, Alpine's GitLab would have looked patched after 22 October, because the version number was right. The hole was still there.
That is the point I would put to any CISO. On a platform you build yourself, in your own container image or with your own components, the headline version number tells you little. The fix may live in an underlying component your build never picked up. Alpine says as much: if you run GitLab on your own Ruby, upgrading GitLab is not enough, and you also need Ruby 3.3.13, 3.4.12, 4.0.9 or later. Their advice to others is to apply critical GitLab security releases within a day and to check every release for component patches your build has to apply.
The report raises a second issue. The attack came in through a newly registered account. If your GitLab, internal or public, allows open sign-up, or lets outside parties trigger pipelines, the attack surface is wider than most teams assume.
Who actually owns your GitLab?
In my view, ownership is where many organisations fall short. GitLab holds your source code, pipelines, deployment keys and often your infrastructure code. Yet ownership tends to fall between the cracks. Development teams use it, infrastructure hosts it, and security looks at it once something goes wrong. A patch that has to land within a day, plus someone checking whether a Ruby fix made it into your own image, does not fit that gap.
My advice is to name a single owner for your development platform and give them a security mandate. That person reads GitLab's release notes the day they appear, knows how your image is built, and has the authority to take the server offline until it is fixed. In practice that is a DevSecOps engineer or a platform engineer with security experience. If you have nobody like that, or your one person is tied up elsewhere, bringing in an interim specialist is the obvious move.
For organisations covered by the Cyberbeveiligingswet, the Dutch law implementing NIS2 that has applied since 15 August 2026, this is also a board matter. You must take appropriate and proportionate measures to secure your network and information systems, the board approves those measures and oversees them, and incidents must be reported as quickly as possible and within 24 hours at the latest. A critical flaw with a patch available and a documented exploitation attempt is exactly the kind of event a regulator will later ask about: what did you do, and when?
What to do now
Ask your engineers today which GitLab version you run, whether it is an official GitLab package or your own build, and if it is your own build, which Ruby version is inside. A custom build on Ruby older than 3.3.13, 3.4.12 or 4.0.9 is vulnerable even when the GitLab version looks correct.
If your GitLab was reachable from outside between 12 October and your upgrade, check that window for worker crashes and for new accounts starting pipelines. Alpine showed that when in doubt, rebuilding and rotating keys beats hoping for the best. You will want someone with DFIR experience for that.
The PHP2Shell vulnerabilities earlier this month followed the same pattern. Applying the update is quick. Working out where everything runs, and who picks it up, is what takes the time.
Need a DevSecOps specialist or a vulnerability management lead to drive patches like this through to the last server? Through MVPeople we place interim security professionals. Call or email me via our contact page and we can work out what you need.
