> 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...
Gigachad 50 minutes ago [-]
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.
jamesfinlayson 35 minutes ago [-]
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.
Operyl 28 minutes ago [-]
Atlassian products (Jira Server) are no longer supported, and their more Enterprise offering dies in 2029, so everything is ending up in their cloud now yeah.
> We have not requested CVE identifiers in Ruby for these fixes, at least for now.
> 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.
couchand 6 minutes ago [-]
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.
weinzierl 42 minutes ago [-]
At the beginning of the industrialization there were many accidents with steam boilers.
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.
edoceo 1 hours ago [-]
The PHP2Shell one was both lucrative and exhausting. I maintain a bunch of legacy PHP apps.
rconti 41 minutes ago [-]
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.
esseph 1 hours ago [-]
It's not maintainable unless you autobuild, and yes, upgrade treadmill.
Gigachad 41 minutes ago [-]
The patch for Ruby came out 6 days ago. Most Rails apps do not use the Ruby from the package manager but have a hardcoded version in the repo. So unless you have developers releasing a PR to update ruby the moment it comes out, you aren't safe.
This might feel like a "Yeah obviously" moment, but the fact is that very few Rails apps are running the latest ruby release the moment it comes out.
edoceo 20 minutes ago [-]
True for many others right? PHP, Python, JS, Lua..what if some finds an old exploit in Perl, oh heck.
awesome_dude 44 minutes ago [-]
> 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
jtchang 20 minutes ago [-]
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.
andrewinardeer 31 minutes ago [-]
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.
missmewiththatl 26 minutes ago [-]
We've adopted a zero-risk posture at our org. We've taken down numerous amounts of services over the last few weeks related to PHP, Node, and Python until things are properly vetted.
We joked in our last internal meeting that this is the end of public software... I have a feeling we may be right, at least in the very short term.
Gigachad 28 minutes ago [-]
That's what Meltdown, Spectre, Rowhammer, and other hardware bugs have been. While you can't patch the hardware, there have always been software level mitigations.
Thankfully a lot of the low level stuff is just not that exposed to the network so even if you find a bug in some firmware, you still have to find a way to access it over the network.
cowlevel 47 minutes ago [-]
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?
Gigachad 44 minutes ago [-]
I've been calling this out for forever now and have been repeatedly told that actually, competent devs with C are fine and the C software we use has been battle tested so it's largely secure.
And now we are seeing that was all untrue.
cristoperb 27 minutes ago [-]
now it's even more battle tested!
2 hours ago [-]
2 hours ago [-]
Rendered at 01:43:39 GMT+0000 (Coordinated Universal Time) with Vercel.
> 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...
https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-fo...
> We have not requested CVE identifiers in Ruby for these fixes, at least for now.
> 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.
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.
This might feel like a "Yeah obviously" moment, but the fact is that very few Rails apps are running the latest ruby release the moment it comes out.
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
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.
We joked in our last internal meeting that this is the end of public software... I have a feeling we may be right, at least in the very short term.
Thankfully a lot of the low level stuff is just not that exposed to the network so even if you find a bug in some firmware, you still have to find a way to access it over the network.
Who else is tired of C libraries since this week?
And now we are seeing that was all untrue.