> 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...
If someone wants to vibe code an alternative to a SaaS tool, my gut feeling is "no, this is bad and it will blow up" as vibe-coded projects tend to do.
But then the alternative is often paying $X million per year for licenses to a half-assed program that hasn't had a UI update since 2005.
I just don't have a good argument on why they shouldn't when the outcome will be just as dogshit, only cheaper and flashier.
I’m doing my part!
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.
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.
Alongside the current scanning and patching of software.
I don't think that lasts, I've seen at least 5 viable replacements now. All internal projects at major US companies.
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.
Security is always reactive by its very nature. You can do proactive things, but you will always be reactive to novel attacks.
Expect everything to have various levels of rolling upgrades, and soon. That's a lot of work.
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.
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
Linux has the very same disturbing not invented here syndrome, rewriting good features by their own, making them worse.
Who else is tired of C libraries since this week?
And now we are seeing that was all untrue.
How about being constructive instead - old bug in old code is no surprise, no matter the language/technology.
https://www.darpa.mil/research/programs/translating-all-c-to...
shouldn't they tag a new version instead of re-releasing a fixed 19.3.6, if earlier 19.3.6 are vulnerable?
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.
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.