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

Posted by sashk 5 hours ago

Comments

Comment by JLO64 5 hours ago

> 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...

Comment by Gigachad 4 hours 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.

Comment by jamesfinlayson 4 hours 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.

Comment by Operyl 4 hours 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.

Comment by egeozcan 3 hours ago

I know a lot of companies vibe-coding alternatives. I'm not an expert but it's perhaps even illegal for most European companies to migrate any customer data to Atlassian servers.

Comment by StableAlkyne 16 minutes ago

This is something I keep struggling with.

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.

Comment by griffiths 3 hours ago

Can you give more information on "illegal for most European companies" part? Asking for a EU company using Jira :)

Comment by Sebguer 2 hours ago

This person is just posting absolutely baseless claims, as if Atlassian, a company that basically exists purely on the back of B2B SaaS sales, has not considered EU data residency requirements in their core product offering: https://www.atlassian.com/software/data-residency

Comment by jamesfinlayson 1 hour ago

Yeah I thought Jira at least was all built on AWS these days. I've never set up a Jira Cloud instance but I'd be surprised if you don't chose where your data lives.

Comment by bombcar 3 hours ago

This is how SaaS dies, vibe-coded to death.

I’m doing my part!

Comment by milkshakes 4 hours ago

this is a really bad look in 2026 imo

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.

Comment by couchand 3 hours 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.

Comment by Blackthorn 2 hours ago

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.

Comment by milkshakes 36 minutes ago

> It's a Bad Idea (TM) to compile a regular expression from an untrusted input.

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?

Comment by 0x1F8B 3 hours ago

> 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.

Comment by pixl97 2 hours ago

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.

Comment by Gigachad 3 hours ago

That's a for now problem. The future is probably less software surface area exposed to the internet, the removal of unsafe languages from software exposed to the network, services like Cloudflare deploying firewalls to detect exploit attempts, and services that can keep a live database of currently active bots and residential proxies to IP block them.

Alongside the current scanning and patching of software.

Comment by 0x1F8B 2 hours ago

I don't disagree. Also probably more logs and more metrics since LLMs can scale instrumentation, signals and auditing far beyond what humans could ever process, which in turn, more tokens. Probably larger Datadog bills too.

Comment by esseph 2 hours ago

> Probably larger Datadog bills too.

I don't think that lasts, I've seen at least 5 viable replacements now. All internal projects at major US companies.

Comment by edoceo 5 hours ago

The PHP2Shell one was both lucrative and exhausting. I maintain a bunch of legacy PHP apps.

Comment by weinzierl 4 hours 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.

Comment by bombcar 3 hours ago

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.

Comment by esseph 2 hours ago

> 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.

Comment by weinzierl 9 minutes ago

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.

Comment by rconti 4 hours 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.

Comment by jayd16 2 hours ago

Dynamically linked dependencies? CI and semver aware automatic dependency tracking? Automatic updates pointed at personal app depots?

Comment by esseph 5 hours ago

It's not maintainable unless you autobuild, and yes, upgrade treadmill.

Comment by Gigachad 4 hours 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.

Comment by edoceo 4 hours ago

True for many others right? PHP, Python, JS, Lua..what if some finds an old exploit in Perl, oh heck.

Comment by awesome_dude 4 hours 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

Comment by rurban 14 minutes ago

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.

Comment by akersten 1 hour ago

> 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?

Comment by looperhacks 17 minutes ago

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

Comment by cowlevel 4 hours 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?

Comment by Gigachad 4 hours 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.

Comment by cristoperb 4 hours ago

now it's even more battle tested!

Comment by awesome_dude 2 hours ago

Let's rewrite everything - said every 15 minutes by every new developer with a new toy.

How about being constructive instead - old bug in old code is no surprise, no matter the language/technology.

Comment by Gigachad 2 hours ago

This was hardly a convincing argument before the current CVE explosion. By now C needs to be dead and buried for network accessible code.

Comment by eviks 4 minutes ago

How is this constructive when you're offering nothing to construct? Just saying not to be surprised.

Comment by fartfeatures 2 hours ago

Someone needs to tell DARPA:

https://www.darpa.mil/research/programs/translating-all-c-to...

Comment by grg0 3 hours ago

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?

Comment by jooops1 3 hours ago

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.

Comment by Fordec 46 minutes ago

[profile.release] overflow-checks = true

Comment by ferrisjoke 2 hours ago

I've heard the joke many times, but I didn't expect that even programming would ever end up wanting to evolve to crabs.

Comment by ab_wahab01 16 minutes ago

Is there any scanner that would catch this?

Comment by jtchang 4 hours 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.

Comment by stevepike 3 hours ago

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.

Comment by literallyroy 2 hours ago

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

Comment by andrewinardeer 4 hours 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.

Comment by missmewiththatl 4 hours 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.

Comment by xtracto 1 hour ago

Hey hey, i called it!

https://news.ycombinator.com/item?id=50189092

Comment by fhn 3 hours ago

your linux distro is built on perl and python

Comment by Gigachad 4 hours 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.

Comment by wilson-draugr 1 hour ago

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.

Comment by milkshakes 34 minutes ago

not sure why this was flagged, it's completely on point.

Comment by 5 hours ago