Live data from Hacker News

GitHub RCE Vulnerability: CVE-2026-3854 Breakdown

wiz.io

21–30 of 97 posts

Re: GitHub RCE Vulnerability: CVE-2026-3854 Breakdown

#21

> April 28, 2026 > GitHub Enterprise Server customers should upgrade immediately - at the time of this writing, our data indicates that 88% of instances are still vulnerable > Upgrade to GHES version 3.19.3 or later https://docs.github.com/en/enterprise-server@3.19/admin/rele... : > Enterprise Server 3.19.3 - March 10, 2026 88% of on-prem customers haven't applied a critical security fix from 7 weeks ago, that seems…

I assume a fair amount of these on-prem customers restrict access to their GHES instance to be behind corporate VPN or something similar and are planning a date to upgrade their instance that won't affect operations.

Any public instance should update immediately though, it's not very hard to put together how to repro the vulnerability on your own from what they provide in the article and the fact that GitHub Enterprise source is publicly available.

Re: GitHub RCE Vulnerability: CVE-2026-3854 Breakdown

#22
post #7
post #5

Earlier quoted context omitted.

Question is how fragile the upgrade process is in large installations. In other enterprise software messing around with large amounts of data I've seen the smallest things break the install and leaving the OPs team rolling back. Was like SharePoint in the past, you were rolling a dice when upgrading it.

It's incredibly fragile. It breaks a vast majority of the time and takes multiple rounds of support on-call to upgrade typically.

Unsurprising for a fourth tier on-prem created by cutting a continuously deployed application into releases.

Re: GitHub RCE Vulnerability: CVE-2026-3854 Breakdown

#24
post #17
post #2

People keep wanting to replace GitHub, but with what? If GH is getting RCE's this late in the game who wants to take the chance something else won't?

A "reasonable" answer is probably a primary self-hosted Forgejo instance as the canonical forge, while using GitHub as a mirror solely to take advantage of its free CI, while that lasts, while hosting secrets with a dedicated secret-hosting provider (I don't know what the provider du jour for this is these days).

> solely to take advantage of its free CI, while that lasts

Eh, if you want to be able to continue working, deploy and what not as normal during weekdays, I'd suggest also moving to Forgejo Actions if you're moving anyways. Not 100% compatible, but more or less the same, and even paying the same but with dedicated hardware you'd get way faster runners.

Re: GitHub RCE Vulnerability: CVE-2026-3854 Breakdown

#25

Earlier quoted context omitted.

Enjoy your experience, there will certainly be no end to it.

I've had my account since 2008. ¯\_(ツ)_/¯ updated: changed the date to 2008. my account shows 2001, but that's probably from projects I moved over... proof: https://github.com/lookfirst

Just be careful your patronage doesn't lead to a sunk cost fallacy---a middle manager might just be betting on it

Re: GitHub RCE Vulnerability: CVE-2026-3854 Breakdown

#26

Earlier quoted context omitted.

I've had my account since 2008. ¯\_(ツ)_/¯ updated: changed the date to 2008. my account shows 2001, but that's probably from projects I moved over... proof: https://github.com/lookfirst

Just be careful your patronage doesn't lead to a sunk cost fallacy---a middle manager might just be betting on it

I have no ingrained loyalty, I just haven't found something better.

Re: GitHub RCE Vulnerability: CVE-2026-3854 Breakdown

#27
post #16

GitHub case will be thought in schools how to screw up almost monopolistic position in the market in couple years. This is beyond bonkers.

Only if they take Skype off the syllabus first.

private equity: hold my beer!

Re: GitHub RCE Vulnerability: CVE-2026-3854 Breakdown

#28
post #20

Earlier quoted context omitted.

Replace a whole 24/7 team of devops people with myself? As much as I'd like to believe that I'm worthy, I'm not.

If the primary forge's only job is to host the actual Git infrastructure (the code, the MRs, the issues, maybe a wiki), it's a lot more simple than GitHub, and probably more within the scope of what people can reasonably administer themselves.

I hosted the first "java.apache.org". I was an early employee at CollabNet, and in the first discussions around starting subversion. I worked on Cloud Foundry.

This stuff isn't easy and I'm more than happy letting someone else do it at the expense of some downtime.

Post reply on HN