> 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 the 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...
At this point if you are self hosting you should have everything behind a VPN. Only companies with their own security and development teams should be putting things on the public internet.
Gosh I'm at a big company and I'm pretty sure all the self-hosted tools are only accessible through VPN-like tech anyway. The only truly public stuff is Jira, Confluence (which I assume it more to do with Atlassian's pricing of self-hosted) and Sharepoint.
> build from source or make their own images vs those who rely on provided images and upgrade them often.
I mean - this incident brings it into sharper focus - but it's always been thus.
As a Go developer I often tell people "Be wary of vendoring, you are creating a cache of dependencies that need to be managed and maintained"
Or people that "pin" dependencies, they face the same difficulty.
Why not just use "official" (in this case) images - sometimes they lag too - hell, most Linux distributions lag so much with Go compiler packages that, again, I routinely tell people to avoid them in favour of watching the Go official page
What’s interesting with steam boilers and other types of OSHA related injuries is that it’s not enough that the person who’s doing the stupid thing dies: you have to enforce it even more and even higher. People won’t value their life.
We don't do rolling upgrades on steam boilers nor do we do it on our door locks. Nothing is perfect, we just need good enough and we are currently far away from good at all.
When it comes to software it hasn't always been the case. Before the Internet software was considered something stable and even now there are areas, like functional safety critical software, where this is true to some degree.
It's not that it can't be done.
It used to be expensive to a certain extent it will stay expensive, but modern languages, tooling and formal methods will hopefully mitigate that enough.
The world has changed but 15 years ago we thought it was utterly insane to just pull whatever $latest from $internetsite.probablytrusted.org as part of your build and deployment process.
> Ruby has generally considered it unsafe to compile and use a regular expression created from untrusted input. We stated this in the advisory for CVE-2022-28738, where we nevertheless treated a double free in Regexp compilation as a vulnerability after a comprehensive assessment. We did the same for CVE-2024-27282.
It's a Bad Idea (TM) to compile a regular expression from an untrusted input.
Despite what anyone would try to sell you, a regular expression is a programming language. It's Always A Bad Idea (TM) to compile untrusted input into any kind of programming language. Don't string concatenate SQL queries, eval is evil, it's all the same idea.
A regex might be a programming language, a proper regular expression (which there are libraries for, like Google RE2) is just a regular language and I don't think you can even charitably call that a programming language.
> 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 future is near constant burning of tokens in your software factory to do this automatically. The labs create the increase in demand for their own product.
Turns out building the world on an infrastructure of lies has finally caught up with us.
The way LLMs are developed now is but one possible future we could have experienced. Imagine the future where the LLMs were built by a few governments with black budgets and hidden until a war or some other large event broke out. Then suddenly most of the computers and digital infrastructure shits itself as everything goes wonky.
At least this way we get to see that a shared global infrastructure built on the idea that security is someone else's problem was a really bad idea and we might have enough time to fix it or pull enough plugs we don't go back to the dark age.
And how does Rust help? As far as I know, an integer overflow in Rust panics in debug but just wraps in release (a bad choice in my opinion). Would it help specifically in the code execution part of the exploit?
The key difference is even If an Integer overflows in Rust It still doesn't violate memory safety in safe Rust and therefore doesn't lead to exploitation.
Depends on what kind of exploitation you're talking about -- integer overflows can still cause out of memory conditions and crash the program, which is a denial-of-service vulnerability when talking about webapps.
But yes, memory-save languages like Rust are a massive help protecting against remote code execution. (unless said memory-safe language introduces its own category of RCE vulnerabilities, e.g. deserialization in Java)
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.
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.
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!
> 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?
Image tags are not are versions and shouldn't be treated as such. The tag "19.3.6" refers to the version of Gitlab, which hasn't changed. This is why everyone should pin their images to a specific sha and setup a process to get notified on changes
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.
Just get the source code of Forgejo, audit it thoroughly and run an instance of that.
Thinking that Forgejo is a viable replacement for someone who uses GitLab is wild. It's a bit like telling someone to use cgit instead of Forgejo. (yes I know Alpine uses cgit as well)
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!
47 comments
[ 0.29 ms ] story [ 22.8 ms ] threadI 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 the 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...
I mean - this incident brings it into sharper focus - but it's always been thus.
As a Go developer I often tell people "Be wary of vendoring, you are creating a cache of dependencies that need to be managed and maintained"
Or people that "pin" dependencies, they face the same difficulty.
Why not just use "official" (in this case) images - sometimes they lag too - hell, most Linux distributions lag so much with Go compiler packages that, again, I routinely tell people to avoid them in favour of watching the Go official page
We've git that under control with regulation and the help of organizations, some of which still exist today.
This "era of constant exploits/patches" is not normal and can't go on. Currently it is an ongoing cat and mouse game, but it doesn't have to be.
When it comes to software it hasn't always been the case. Before the Internet software was considered something stable and even now there are areas, like functional safety critical software, where this is true to some degree.
It's not that it can't be done.
It used to be expensive to a certain extent it will stay expensive, but modern languages, tooling and formal methods will hopefully mitigate that enough.
https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-fo...
> Ruby has generally considered it unsafe to compile and use a regular expression created from untrusted input. We stated this in the advisory for CVE-2022-28738, where we nevertheless treated a double free in Regexp compilation as a vulnerability after a comprehensive assessment. We did the same for CVE-2024-27282.
Despite what anyone would try to sell you, a regular expression is a programming language. It's Always A Bad Idea (TM) to compile untrusted input into any kind of programming language. Don't string concatenate SQL queries, eval is evil, it's all the same idea.
i agree with you!
nevertheless,
> where we nevertheless treated a double free in Regexp compilation as a vulnerability after a comprehensive assessment
not sure what sort of comprehensive assessment is still called for at this point?
The future is near constant burning of tokens in your software factory to do this automatically. The labs create the increase in demand for their own product.
The way LLMs are developed now is but one possible future we could have experienced. Imagine the future where the LLMs were built by a few governments with black budgets and hidden until a war or some other large event broke out. Then suddenly most of the computers and digital infrastructure shits itself as everything goes wonky.
At least this way we get to see that a shared global infrastructure built on the idea that security is someone else's problem was a really bad idea and we might have enough time to fix it or pull enough plugs we don't go back to the dark age.
Who else is tired of C libraries since this week?
But yes, memory-save languages like Rust are a massive help protecting against remote code execution. (unless said memory-safe language introduces its own category of RCE vulnerabilities, e.g. deserialization in Java)
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.
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.
shouldn't they tag a new version instead of re-releasing a fixed 19.3.6, if earlier 19.3.6 are vulnerable?
Linux has the very same disturbing not invented here syndrome, rewriting good features by their own, making them worse.
Just get the source code of Forgejo, audit it thoroughly and run an instance of that.
I like Forgejo btw, but these days everything is vulnerable. Switching tools isn’t the final answer
In this situation, wouldn’t the more responsible behaviour of gitlab be to blacklist Ruby runtimes that enable the CVE?