Posted by bo0tzz 19 hours ago
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.
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.
> 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.
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).
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 ...
Another data point against doing security through obscurity.
If GH is getting RCE's this late in the game who wants to take the chance something else won't?
As much as I'd like to believe that I'm worthy, I'm not.
This stuff isn't easy and I'm more than happy letting someone else do it at the expense of some downtime.
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.
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.
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.
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.
"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.
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.
updated: changed the date to 2008.
my account shows 2001, but that's probably from projects I moved over... proof: https://github.com/lookfirst
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.