GitLab Security Incident: Attempted Exploitation of CVE-2026-97229

> Upgrading to GitLab 19.3.6 on October 22 didn’t fix the vulnerability. The fix isn’t in GitLab’s own code but in a patch to Ruby, which GitLab applies only in its official packages. Our image used standard Ruby, so it didn’t get the patch.

> The bug is in Ruby’s regular expression engine, so any program that compiles regular expressions from untrusted input is exposed, not only GitLab.

I feel like this era of constant exploits/patches is really bad for those who build from source or make their own images vs those who rely on provided images and upgrade them often. I really can't think of a decent solution for those people other than being plugged in 24/7 to the latest news which is really unfortunate and must be exhausting...

The bug is integer overflow in a random C data-processing library (specifically regexes) leading to RCE.

Who else is tired of C libraries since this week?

> If you use our alpinelinux/gitlab container image, pull alpinelinux/gitlab:19.3.6 again. The image published on October 27 contains Ruby 3.3.13. Any 19.3.6 image you pulled before October 27, and all older tags, are vulnerable.

shouldn't they tag a new version instead of re-releasing a fixed 19.3.6, if earlier 19.3.6 are vulnerable?

This is a fantastic write up on the security incident. Almost any incident like this will have unknowns. It's good to make it explicit. I especially liked the part of what would have been leaked if the attacker was successful. Maybe they could include what type of hash was used.

If Alpine prides themselves on focusing so much on security, they probably shouldn’t use GitLab - the attack surface is too great and it’s never going to be easy to keep safe and up to date fully, unless you have FTEs whose main job is just maintaining it.

Just get the source code of Forgejo, audit it thoroughly and run an instance of that.

With the eMudhra situation we saw e.g. Go doing an emergency release that blacklists the certs, while they aren’t shipped with Go, as a protection of dependencies that haven’t caught up.

In this situation, wouldn’t the more responsible behaviour of gitlab be to blacklist Ruby runtimes that enable the CVE?

pretty nice to see that despite suspecting it wasnt really successful, a rebuild and thorough process was followed. lack of evidence doesnt mean nothing happened. better safe than sorry. classy response, hats off!

Does anyone know for sure which unsupported versions of ruby are affected? Best I can tell 3 of the four affect old versions of ruby that are not getting a security patch for this. Update your ruby!

I do think CVE-2026-89078 - the double free one - may only affect ruby 3.3.11 and above. It relies on a bug introduced in ruby 3.4/4 via https://github.com/ruby/ruby/commit/8cd295ecf0 and backported (maybe accidentally?) in 3.3.11/12 in https://github.com/ruby/ruby/commit/e02c892ade. So that one is getting patched on all rubies it would have affected.

This was happens when you don't trust existing well-maintained packages, and rather rewrite it by your own. Onigmo should not exist.

Linux has the very same disturbing not invented here syndrome, rewriting good features by their own, making them worse.

I feel like this title downplays the scenario. I read “attempted” as unsuccessful, not as maybe entirely successful.

Is there any scanner that would catch this?

use stupid software, win stupid prices. gitlab is overbloated human slop.

The nasty part is that a version scan would have called that 19.3.6 image fixed. The CVE is filed against GitLab, and 19.3.6 is past the fixed version. The actual fix is in Ruby, and Ruby shipped it without requesting a CVE, so anything scanning the Ruby in the image has no advisory to match. If you build GitLab yourself, you had to read GitLab's release notes and then check which Ruby you were on.

[dead]

[dead]

Have researchers coined the term `Superbug` or `MegaVuln` yet?

Surely we're approaching a point where an LLM discovers a critical, unfixable vulnerability in every device running any version of $OS, then irresponsibly discloses it, triggering mass collective trauma among admins worldwide, significant downtime in critical infrastructure and scores of deaths.