I know it's easy to say after the fact but still, wtf
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)
> 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 ...
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.
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.
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.
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.
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.
