> 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 ... bad.
They are constantly telling all their GHES customers who complain about the severe flaws with the self-hosted appliance product to move to GitHub Enterprise Cloud, which is just regular GitHub.com, but who in their right mind would make that move nowadays??? At least GHES stays up during the daily github.com outages.
It's still a pretty annoying process, though.
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.
Guess which is usually picked ...
Security research historically has two difficult components that build on one another: 1. Understanding complex system internals: uncovering the inner workings hidden by abstractions or interfaces 2. Finding vulnerabilities in these uncovered mechanisms
Sometimes both steps are equally hard. But often, finding the vulnerability is trivial once the real mechanisms are uncovered, rather than relying on assumptions about inner workings.
CVE-2026-3854 is a case where the vulnerability is not plainly obvious after understanding the internals. Still, I am confident that this command injection would have been found quickly had it been exposed to a more traditional or accessible attack surface.
But recently this signal got somewhat scrambled, or being sabotage by c++ fan boys (those coding AIs would help getting rid of dev/vendor lock-ing using c++ syntax complexity)
I know it's easy to say after the fact but still, wtf
"Trusted by more than 50% of Fortune 100 companies".
You choose to give your most precious data and the keys of infrastructure whose job was to steal information and with people that are still NSA/8200 employees.
Don't be surprised if one day they are compelled to share data or find dirt on people (they protect one well known LLM company).
It doesn't mean they are doing it, but clearly the incentive for it exists, + you are exposed to both US and IL jurisdictions risk.
And yet when I do something a bit dodgy (like query a DC with a cli, and reset credentials) it's silent...
> babeld copies git push option values directly into the X-Stat header - without sanitizing semicolons. Since ; is the X-Stat field delimiter, any semicolon in a push option value breaks out of its designated field and creates new, attacker-controlled fields.
They managed to literally do the simplest possible thing wrong. The fruit was hanging so low it might have been underground.
If GH is getting RCE's this late in the game who wants to take the chance something else won't?
Also, this was about as bad as a vulnerability can get. It’s not exaggerating to say that all private code on GitHub should be considered compromised because of this issue. An anonymous user could have read every single private repo. To me, that warrants BREAKING.
Another data point against doing security through obscurity.
And yet another lesson to not treat data as instructions. Sanitize all user input!
As we have known for a while, they ended up being really good at translating source to source or text to source. It shouldn't be too surprising they are also really good at understanding the asm version too.
Doesn't make it any less impressive, but maybe less surprising.
edit: I didn't mean it as a put-down of either the article or how they found the vulnerability, but it wasn't a constructive comment either way.
As much as I'd like to believe that I'm worthy, I'm not.
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.
I was pleasantly shocked that Forgejo is literally a single binary with a relatively easy config. All my internal services reference my Forgejo instance so, if I need to bail on GitHub, it's low friction for me.
The all-in-docker image and a couple of gitlab runners is all small to medium sized teams need. (Don't overcomplicate it with the kubernetes version unless you really need it)
https://status.gitlab.com/pages/history/5b36dc6502d06804c083...
replace it with git.
if you want a whole ui you can use something like forgejo which has far fewer features likely leading to less issues.
They're just aligning themselves with US foreign policy.
updated: changed the date to 2008.
my account shows 2001, but that's probably from projects I moved over... proof: https://github.com/lookfirst
For OSS, the unlimited free minutes of multiplatform CI offered by GitHub are literally impossible to replace. Maintaining runners yourself to do the same things would be somewhere between a part- and full-time job.
"Codeberg is a non-profit, community-led effort that provides services to free and open-source projects, such as Git hosting (using Forgejo), Pages, CI/CD and a Weblate instance."
Never say impossible.
Github is still "new" to a lot of us. OSS existed well before it, and will continue to exist well after.
And yes, if we make OSS just about hosting the code, things are much simpler. If you're a piece of desktop software though, and you have users, they'll typically (and reasonably) want auditable signed binaries on all the platforms you support, which requires multiplatform CI.
Yeah, how you think the ecosystem got by before GitHub even had actions? Y'all don't remember Travis CI et al anymore?
There are more CI services than what Microsoft offers the world, sometimes it's worth looking around a bit.
And on equal footing, I trust our security more than theirs. Case in point.
This stuff isn't easy and I'm more than happy letting someone else do it at the expense of some downtime.
I wish they had a plan to literally host GHES for you because then more people in the company would be forced to reckon with how terrible GHES is from an operational perspective. It is stuck ca. 15-20 years ago conceptually.
They don't host github enterprise server for you (though gitlab has something called gitlab dedicated which they host gitlab ee for you).
Perhaps this header mentioned in the article is related, maybe that's the toggle for the enterprise mode? Seems there is at least traces of "enterprise mode" on the normal github servers.
The parent comment was talking about the "GitHub Enterprise Cloud" not "GitHub Enterprise Server" which are two distinct products.
The way that they where able to escalate the RCE from a GHES environment to github.com environment is by injecting this header and enabling this enterprise feature. This supports the idea that "Github enterprise cloud is on github.com".
No, I don't want to be in the business of running my own Github clone. That's what I pay Github for.
Why do you pay salary to employees to buy food when you can just run a farm next to the office and save money by operating the farm and giving the employees food directly? You'd save money by not having to pay as high of salaries, and farms don't even need 24/7 devops teams.