GitLab critical patch release

Posted by artooro 16 hours ago

Counter361Comment85OpenOriginal

Comments

Comment by jimmyl02 14 hours ago

Awesome find by https://hackerone.com/joaxcar and it's a little bit frightening that this severe of a bug isn't the biggest security vulnerability of today

Comment by xmcp123 9 hours ago

It’s the 2020s baby, this one is lucky to break the top 3!

Comment by jacquesm 9 hours ago

Give it an hour or so and there will be a bigger one.

Comment by cindyllm 9 hours ago

[dead]

Comment by molf 3 hours ago

This seems super light on details and I had to dig to find more information. We don't use Gitlab, but we do use Ruby, so I was worried we might be impacted.

This is the best overview I found: https://lilting.ch/en/articles/gitlab-cve-2026-110264-org-mo...

The bottom line: this is an issue in Ruby's regex engine, which was fixed in April and backported recently. [1]

Everyone running applications where attacker-controlled input might find its way (unescaped) into Ruby regexes is vulnerable to remote code execution.

[1]: https://github.com/ruby/ruby/pull/16801

Comment by zahlman 3 hours ago

So the problem is in Ruby itself? Not in onigmo, or in oniguruma? If simply updating Ruby fixes the problem... is GitLab vendoring a Ruby runtime or something? Or has Ruby not published this fix yet?

… Or is the GitLab/onigmo bug about failing to escape regex input?

Comment by jarofgreen 1 hour ago

Depends how you install GitLab. If you just run one of their containers in Kubernetes or whatever then yeah they are packaging Ruby.

Comment by justrunme 2 hours ago

[flagged]

Comment by miduil 13 hours ago

At least second regex related CVE in GitLab in the past few weeks. Awful to see that the endpoint is reachable unauthenticated, but I'm glad that they provide guidance in how to check the logs for attempts of exploitation

Comment by dvdkon 13 hours ago

As far as I can tell, it requires forcing GitLab to render a malicious org-mode file. I don't really see a way to do that without authenticating and uploading one. Am I missing something?

Comment by merb 13 hours ago

    The attack needs no authentication — only one public project that can hold the .org payload.
So probably not vulnerable if no public projects exist - ie self hosted has an needs auth for everything mode.

Comment by boxed 3 hours ago

"Can hold"? Meaning the attacker needs push access to a public repo?

Comment by ezekg 14 hours ago

Is this a bug in GitLab or in Ruby? It's hard to tell from the report and the patch...

Comment by bradly 12 hours ago

Comment by asveikau 9 hours ago

The module in that diff being called "onig" is quite unfortunate, the error codes look like a slur.

Comment by pqdbr 14 hours ago

Or Rails...

Comment by hobofan 13 hours ago

This is shaping up to be the single worst security news day ever. Given the role that AI played in some of the discoveries, one has to wonder if this marks the start of some dark age of IT security.

Comment by choilive 13 hours ago

I think this marks the beginning of the golden age. Investments in automated agent driven security scans on all software is coming to every business. Software and infrastructure will become more secure than ever before.

Comment by hobofan 13 hours ago

I also hope that we come out in a golden age, but we are very much in for a rough few months/years where all the low hanging fruit is being picked up until we end up with much more hardened systems.

Comment by eviks 6 hours ago

Why would it be more secure if there is even more investment in automated agent driven insecure code generation that can outpace any scan capacity?

Comment by riffraff 5 hours ago

If catching "all" security issues becomes feasible then the balance tilts in favor of the projects vs the attackers.

Big malicious entities always had more investments in this than random open source projects.

Comment by eviks 5 hours ago

Since you need an unrealistic if, I presume you agree that the balance doesn't shift?

Comment by vee-kay 12 hours ago

[dead]

Comment by smashed 13 hours ago

This has been going on for months actually with no end in sight.

Comment by hobofan 13 hours ago

Maybe I'm not enough in the weeds to see it as much, but the last few months seem to have been a much slower trickle of "how did we not catch this" exploits, while they are now appearing with much more sophisticated (though still usable in practice) exploit chains on much larger target codebases.

The last few months seem to have been a lot more imunder control with also the frontier labs more warning of "what happens when Mythos-class model get in the hands of everyone" than that actually becoming reality. Now, it appears to be actuually turning into reality.

Comment by UltraSane 11 hours ago

It depends on the net rate of new bugs being made vs the bugs discovered and fixed. Hopefully AI can find bugs faster than new ones are being created.

Comment by flakeoil 4 hours ago

The problem is fixing the bug and not only fixing the code, but applying the fix in production in a timely manner and without interrupting the business.

Comment by reddalo 12 hours ago

> the single worst security news day ever

I'd say, the single worst security news day for now

Comment by itsoverkAIba 5 hours ago

Attack Tokens versus Defense Tokens has already been the norm for the past 2 years. AI is just that good at this game.

It's over. Cybersecurity is now Yugioh, where the lifepoints is your token budget.

Comment by taspeotis 13 hours ago

What? More like a golden age of security. AI is ripping the bandaid off right now. At the end of this software is going to be a lot more secure.

Comment by Gigachad 11 hours ago

That's where we will end up, but the in between time is the worst time ever for trying to secure an internet connected computer.

Comment by jacquesm 9 hours ago

> At the end of this software is going to be a lot more secure.

Can I get that in writing?

As we speak more slop is added to the pile, far more than can reasonably be reviewed and a lot of that code will be insecure.

Comment by zygentoma 43 minutes ago

Code does not need to be reviewed to be secure. [^]

It needs to be designed to be secure.

[^] of course I'm hyperbolic here, it does still need to be reviewed – I just mean, review doesn't matter as much as choosing a secure design, where certain bugs just can not or will not happen.

Comment by jacquesm 26 minutes ago

Code review is just one of many filters. 'Secure designs' are as secure as the designer, and no designer is perfect. Implementations are as secure as the implementors and processes are not perfect either. You need these and many other layers in your filter to be secure for some arbitrary level of security where the final result is roughly proportional to how much money you are willing to expend.

Comment by sellmesoap 6 hours ago

It's ok, we'll just point more LLMs at the new code and the problem will fix itself. In the mean time can we unplug the ethernet cable from the nuke silos for a while?

Comment by jacquesm 3 hours ago

Priorities... you are right.

Comment by esseph 12 hours ago

Did you go to sleep in 2015 and then wake up just now in 2026?

Comment by cobzilla 13 hours ago

Buckle up

Comment by beaconflint 15 hours ago

If you're patching a fleet, gitlab-rake gitlab:env:info gives you the exact version per node, faster than guessing from the omnibus package name.

Comment by perlgeek 14 hours ago

Back in perl 5.8 and older, the regex engine worked by recusing at the level of C functions, and so you could trigger stack overflows by giving it large strings.

Is this similar?

I wonder why gitlab even has its own regex compiler. Or is this a vulnerability in an underlying library or programming language?

Comment by wiml 14 hours ago

Looks like Gitlab ships its own forked copy of the Ruby Onigmo regex engine.

Comment by ezekg 10 hours ago

Why? Is/was Ruby vulnerable?

Comment by bon0r 14 hours ago

possible bug? or too soon to check? :)

after updating a pop-up still shows:

"You are currently on version 19.5.1! We strongly recommend upgrading your GitLab installation immediately."

while 19.5.1 should be the latest and fixed version

Comment by artooro 14 hours ago

Their update checker has never worked very well. It takes hours to stop getting the upgrade warning inside of the GitLab dashboard.

Comment by merb 14 hours ago

I have that aswell…

But I also updated pretty early.

Comment by mqus 11 hours ago

same here, but with 19.4.3

Comment by Thaxll 14 hours ago

What a great week security wise!

Comment by joshAg 12 hours ago

Lemon, it's wendesday

Comment by cogogo 12 hours ago

I picked the wrong week to stop drinking coffee.

Comment by reaperducer 11 hours ago

I picked the wrong week to quit sniffing glue.

Comment by cogogo 11 minutes ago

The downvoters must have missed Airplane!! For a second I thought about how to escape the ! to make it clear it’s part of the title… but I haven’t had any coffee.

Comment by SOLAR_FIELDS 8 hours ago

You should go backto the glue it’s not a good idea to be normal about this. We should all be sniffing glue Charlie day style

Comment by dmd 11 hours ago

I picked the wrong week

Comment by blackmesaind 12 hours ago

It's only Wednesday, plenty of week to go.

Comment by marcellosso 11 hours ago

Sir, it is only wednesday

Comment by tharkun__ 11 hours ago

You spelled Wendy's wrong.

Comment by 14 hours ago

Comment by jeffybefffy519 2 hours ago

Gitlab has such a high rate of vulns, this release ahas 13 fixed and in a week there will probs be another 10

Comment by Geezus_42 1 hour ago

Sounds like every large application I've ever seen.

Comment by yoyohello13 10 hours ago

Gitlab has had a lot lately. I’ve had to patch every other week for the last few months

Comment by Gigachad 7 hours ago

Gitlab is probably more prominent since it's a large enterprise piece of software that's self hosted. Every bug in a library used by Gitlab becomes a problem for Gitlab. While hosted platforms like Github can just update the library and not have to make an announcement.

Comment by 1over137 8 hours ago

And it's not even written in C! /s

Comment by 131hn 12 hours ago

Using AI agent to apply patches & upgrade is now mandatory to keep up with the pace.

Comment by 12 hours ago

Comment by preisschild 7 hours ago

Dont even need "AI" for that. Just renovate.

Comment by nozzlegear 11 hours ago

Cross your fingers and pucker your butt that it doesn't fuck it up.

Comment by jamesfinlayson 11 hours ago

Years ago I worked at a company that had a nightly cronjob for yum to apply security updates (with a couple of important exceptions that were handled manually). Always seemed very iffy to me for such a big company where downtime was very expensive.

Comment by nullsanity 10 hours ago

[dead]

Comment by jraph 12 hours ago

Good luck with the security and the stability of a system managed like this.

Comment by jaequery 11 hours ago

is this a taste of things to come?

Comment by brlewis 9 hours ago

No. Like the PHP vulnerability, this was a bug in a language interpreter written in C, and a bug that would not be possible in most newer languages. Even as secure-by-design becomes more prevalent, there will be vulnerabilities, but this one is a taste of the past.

Comment by muvlon 11 hours ago

The critical CVE (https://docs.gitlab.com/releases/patches/patch-release-gitla...) seems embargoed, just saying that it involves integer overflow in a regex compiler.

Coincidentally, there is also a (non-embargoed) musl libc CVE published today involving integer overflow in its regex compiler: https://www.openwall.com/lists/musl/2026/10/21/1

Perhaps that is the underlying bug, or a similar one turned up by the same security research?

Comment by tptacek 15 hours ago

"CVSS 10.0" isn't in the headline here and a CVSS of 10 doesn't actually mean anything.

Comment by phoe-krk 15 hours ago

Deeper in the article: https://docs.gitlab.com/releases/patches/patch-release-gitla...

GitLab has remediated an issue that, under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server due to integer overflow when compiling a specially crafted regular expression. (...)

CVSS 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)

Here, CVSS 10.0 means arbitrary remote code execution.

Comment by tptacek 15 hours ago

"Arbitrary RCE" does mean something. "CVSS 10.0" does not. We should be using the article headline here.

Comment by phoe-krk 15 hours ago

Truth be told, I don't think that "GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13" is a more descriptive title, even taking the HN guidelines into account. It could be better, sure, but it's not horrible (IMO).

Comment by tptacek 15 hours ago

It's an editorialization. The submitter is saying something about the importance of CVSS that the article does not. A better title would say "Remote Code Execution" where it says "CVSS 10.0" now.

Comment by artooro 14 hours ago

Good point guys, I've updated the title.

Comment by zahlman 2 hours ago

I still remember a supposed 9.9 bug in CUPS (CVE-2024-47176) that was effectively irrelevant for almost everyone. Basically, as I understand it, you'd have to be running a server that let people connect from the public Internet that was also running CUPS for some reason, and then also have someone inside the organization try to print something to a fake attacker-controlled "printer". But it would have been RCE, yes.

My experience has been that CVSS has really just not been very informative or well-calibrated to risk.

Comment by ivanjermakov 15 hours ago

Because "10 out of 10" is a better headline for the average reader than "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H".

Comment by Retr0id 15 hours ago

Sometimes CVSS 10 "oversells" the true severity of a bug but this doesn't seem to be one of those cases.

Comment by TZubiri 15 hours ago

>CVSS of 10 doesn't actually mean anything.

Might you perchance be exaggerating?

Comment by tptacek 15 hours ago

No? CVSS is a Ouija board. Citrix directory traversal got scored 10.0. So did a Cisco Broadworks SSO bypass. Meanwhile, Shellshock did not.

CVSS is like the Pitchfork Music ratings scale. It communicates false precision, and it's easy to point to places where that precision misleads (D-plan's "Emergency & I" is not better than every Yo La Tengo album).

Comment by TZubiri 15 hours ago

Have you read signal/noise theory? That a signal isn't perfect (that it contains false positives or positive falses in case of binary signals, or that it has a delta between the signal and the underlying phenomenon) doesn't mean that it carries no information.

For example if I cry wolf 50% of the time, but 100% of the times there's a wolf I cry wolf. Then no matter what the frequency of wolf sightings are, my crying wolf carries some information (unless there's always a wolf). Assume there's a wolf 1% of the nights, then I will cry wolf 50% of the time, and you only need to check for a wolf 50% of the nights rather than 100%.

It's worth noting that there's still technically signal even if I sometimes miss a wolf, even if you may choose to ignore that signal in order to pursue 100% accuracy yourself.

Comment by nikanj 14 hours ago

It's more like: you work as an animal spotter, and if you tell people you saw a hamster, you'll get no glory. So obviously you spotted a direwolf at least 12 feet tall.

Comment by TZubiri 11 hours ago

Interestingly CVSS was designed to help with this specific issue. You are complaining that the system is imperfect, but you fail to imagine how it works without such a system, everyone tagging their issue as critical.

CVSS is good, it's better than nothing.

Comment by minraws 14 hours ago

I am concerned for my self hosted servers, well only hope is tailscale should be entirely secure, and egress is filtered heavily... If that doesn't work my home lab is fucked.

Any suggestions folks, not even my terminally online self can handle all of these.

Comment by switchbak 13 hours ago

I recently jammed all my stuff behind Tailscale. I sure hope that doesn't burn me.

But it's a lot better than having things live on the open internet!

Also looking at those old C++ services a whole lot differently now.

Comment by acidburnNSA 12 hours ago

Yup just going through the anxiety here. I even self-host my personal e-mail! This is not going to end well.

Comment by preisschild 6 hours ago

I have renovate set to automerge gitlab patch releases

Comment by freedomben 13 hours ago

as a fellow self-hoster, this is a rough time to be us

Comment by nullsanity 10 hours ago

[dead]

Comment by latencyharbor 6 hours ago

[flagged]

Comment by valiant-comma 15 hours ago

[dead]

Comment by murillojndem 14 hours ago

[dead]