alt.hn

4/28/2026 at 4:15:43 PM

GitHub RCE Vulnerability: CVE-2026-3854 Breakdown

 https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854

by bo0tzz

4/28/2026 at 5:46:22 PM

> 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 ... bad.

by bananapub

4/28/2026 at 7:59:03 PM

GHES is essentially unmaintained (perhaps “on life support” would be more charitable since they are certainly accepting payment for it) and has been so for about a decade. It requires a multi-hour downtime to apply even a patch-level release. They do not have any supported mechanism for HA upgrades. So even the most conscientious GHES customers lag the latest version because they can’t afford the downtime.

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.

by semiquaver

4/28/2026 at 8:05:41 PM

You can at least schedule the updates.

It's still a pretty annoying process, though.

by baby_souffle

4/28/2026 at 8:08:32 PM

Until GHES can do zero-downtime upgrades nothing will get better. Not on their roadmap because as far as I’m aware the GHES team doesn’t actually exist or is entirely focused on KLTO. It’s a dead product that they wish didn’t exist.

by semiquaver

4/28/2026 at 9:00:51 PM

Pretty sure GitHub Enterprise Cloud is just Github hosting their enterprise server for you on Azure so you don't have to do the patching yourself.

by everfrustrated

4/28/2026 at 9:57:09 PM

It sure isn’t! GitHub Enterprise Cloud is simply an enterprise plan on the regular multitenant github.com. Your repositories are on disk right next to everyone else that uses github.com. There is no segregated storage or compute.

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.

by semiquaver

4/29/2026 at 4:52:05 AM

[flagged]

by js2

4/28/2026 at 9:19:59 PM

Github enterprise cloud is on github.com and with more features: http://github.com/account/enterprises/new

They don't host github enterprise server for you (though gitlab has something called gitlab dedicated which they host gitlab ee for you).

by securesaml

4/28/2026 at 10:06:55 PM

Why is there an eu github status then ? https://eu.githubstatus.com/uptime

by Kuinox

4/28/2026 at 11:11:42 PM

Data residency is a thing.

by conception

4/29/2026 at 8:07:15 AM

And how would that explain the way higher SLA ?

by Kuinox

4/29/2026 at 11:43:16 AM

> X-Stat header that controls whether the server operates in enterprise mode.

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.

by trashb

4/29/2026 at 12:41:21 PM

There is no “the toggle”. Read the article. A GHES appliance (and github.com) is dozens of services working together, some of which act differently in ES mode, so there are toggles galore. But probably not a lot that can be toggled by user input :(

by semiquaver

5/4/2026 at 2:12:46 PM

I did read the article and that was a direct quote from the section "From GHES to GitHub.com".

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".

by trashb

4/28/2026 at 6:45:52 PM

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.

by brianmcnulty

4/29/2026 at 12:25:52 AM

For sure - the last company I worked at that had GitHub Enterprise had it running on a private network only accessible within the company.

by jamesfinlayson

4/29/2026 at 4:31:44 AM

Yeah, but this still gives any employee RCE on the GHES server right?

by fastest963

4/29/2026 at 5:55:54 AM

I suppose so. The company invested pretty heavily in security tooling, though I think it wouldn't have been hard to do something to bypass the security for internal servers.

by jamesfinlayson

4/28/2026 at 6:38:01 PM

If you're in the enterprise you can update something outside of the normal schedule and guarantee blow up everything (and be blamed) or you can stick with the schedule and hope for the best.

Guess which is usually picked ...

by bombcar

4/28/2026 at 5:57:01 PM

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.

by pixl97

4/28/2026 at 6:00:56 PM

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

by chucky_z

4/28/2026 at 6:49:17 PM

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

by formerly_proven

4/29/2026 at 12:25:05 AM

The GitHub blog had an article saying that all patches must pass for github.com before merge but the GitHub Enterprise tests have a three day window to be rectified.

by jamesfinlayson

4/29/2026 at 2:16:20 AM

I guess I woukd say youre fortunate to have not worked in a "we cannot use github.com because we take security very seriously" environment. Because always tells me you'll be running a on prem product that might get updated once a year.

by technion

4/29/2026 at 5:10:52 AM

On prem beats the heck out of github post Microsoft though... At least you know how to get it working again when someone breaks it. These days with github you expect a weekly 500, a rainbow unicorn error, build failures due to unavailable errors, etc. Last I checked the third party tracker github services were barely pushing one 9 of reliability.

by eyegor

4/28/2026 at 8:39:59 PM

They hint at their AI-augmented reversing methodology, which demonstrates one of the core strengths of current LLM agents. These models, trained extensively on code, can immensely speed up the process of understanding complex system internals.

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.

by jfkimmes

4/29/2026 at 4:52:52 PM

[dead]

by huflungdung

4/29/2026 at 11:33:27 AM

Yep, there was a signal to help reverse engineer c++, as it could have been good at helping c++ mass porting to plain and simple C.

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)

by sylware

4/29/2026 at 12:28:46 PM

So they had a security-critical header whose fields are set by their internal authentication service. And that same field can also contain arbitrary strings passed by the end user with git push -o

I know it's easy to say after the fact but still, wtf

by HenriTEL

4/29/2026 at 4:56:55 PM

Yeah I’m struggling to understand why the same header field would be used for git options in the first place. Why ever allow users to modify that specific header?

by melozo

4/28/2026 at 7:18:28 PM

Anyone in here work at Wiz? Seem like they do pretty good work. Tool itself has survived extreme growth/feature bloat and still does pretty well. Security team has found some really cool stuff.

by jcims

4/29/2026 at 5:46:26 AM

Lots of Unit 8200 peeps.

by az226

4/29/2026 at 1:24:15 PM

Interesting how people sourcing these softwares say China = bad, but Israel = good.

"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.

by rvnx

4/29/2026 at 3:31:48 PM

>China bad, Israel good

They're just aligning themselves with US foreign policy.

by samlinnfer

4/29/2026 at 4:45:59 PM

The founder came from Unit 8200, an Israeli cyberwarfare operation, that’s where the alignment comes from, not simply US foreign policy which is coincidental.

by SlightlyLeftPad

4/29/2026 at 11:43:51 AM

it is too noisy, we just run a custom pipeline which scans with osv-scanner/trivy for critical

by brainzap

4/29/2026 at 7:17:00 AM

I'm not there, but we use it at our place. It triggers on entirely innocent things I do.

And yet when I do something a bit dodgy (like query a DC with a cli, and reset credentials) it's silent...

by jospeh554

4/29/2026 at 1:55:21 AM

> When babeld forwards a push request, one of the internal requests includes push options in the X-Stat header. Git push options are arbitrary strings that users can pass with git push -o. They are a standard git protocol feature, intended for server-side hints. babeld encodes them as numbered fields - push_option_0, push_option_1, and so on - alongside a push_option_count.

> 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.

by saghm

4/29/2026 at 4:23:09 AM

Oh Bobby Tables, your mom was quite clever.

by irishcoffee

4/28/2026 at 4:34:41 PM

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?

by latchkey

4/28/2026 at 6:33:11 PM

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).

by skrrtww

4/28/2026 at 6:39:52 PM

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.

by latchkey

4/29/2026 at 5:10:23 AM

It's the devops team can manage a measly 87% uptime [1] you're talking about, you can do a lot better on your homeserver.

[1]: https://mrshu.github.io/github-statuses/

by rnhmjoj

4/28/2026 at 6:45:06 PM

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.

by skrrtww

4/28/2026 at 7:10:46 PM

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.

by latchkey

4/28/2026 at 11:14:05 PM

24/7 devops team for a forgejo instance? Come on mate...

by slopinthebag

4/28/2026 at 11:31:31 PM

24/7 devops team for github? Come on mate...

by latchkey

4/29/2026 at 12:09:10 AM

Is running a small forgejo instance for a team the same as running GitHub?

by slopinthebag

4/29/2026 at 3:46:00 AM

Will I have to patch machines, keep packages updated, deal with SSL certs, maintain action runner infra, deal with billing for the machines, add monitoring, alerts, logging, etc

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.

by odie5533

4/29/2026 at 4:10:52 AM

Don't you think the farm example was a bit too extreme for it to make sense? A tech company probably does not have expertise in farming but devOps is something they already know how to do and can easily manage it in-house. Also how fast do you think farms produce food that you can drip feed it to employees constantly

by altmanaltman

4/28/2026 at 6:57:52 PM

> 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.

by embedding-shape

4/28/2026 at 8:40:15 PM

For companies with resources for infrastructure, sure.

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.

by skrrtww

4/29/2026 at 1:00:52 AM

> https://docs.codeberg.org/ci/

"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.

by esseph

4/29/2026 at 4:58:58 AM

If Codeberg starts offering Mac and Windows runners alongside their Linux ones for free (or at an achievable price point) for a modest OSS project I'll certainly look at it very closely. If all I needed was a Linux runner, I'd probably be on there already.

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.

by skrrtww

4/28/2026 at 9:07:13 PM

> For OSS, the unlimited free minutes of multiplatform CI offered by GitHub are literally impossible to replace.

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.

by embedding-shape

4/28/2026 at 6:24:53 PM

I am personally now drawing a clear delineation between projects for my internal consumption (e.g. ansible scripts) and projects that have potential use for the general populace. For the prior, I now host a private Forgejo instance. For the latter, I'll put it on GitHub but mirror it to my Forgejo instance.

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.

by Caligatio

4/29/2026 at 12:56:44 AM

We moved from github to a self-hosted forgejo instance about 6 months ago, works like a charm. Still can't belive how snappy forgejo is / laggy github has become

by asa977

4/28/2026 at 10:27:00 PM

Self hosted gitlab behind a VPN.

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)

by crimsonnoodle58

4/28/2026 at 6:00:39 PM

GitLab ?

by gtech1

4/28/2026 at 6:04:22 PM

The people who suggest gitlab, haven't used it. But I guess I could be tempted to try again...

https://status.gitlab.com/pages/history/5b36dc6502d06804c083...

by latchkey

4/28/2026 at 8:17:40 PM

If you could only choose from github, gitlab and atlassan then I suppose.. But really anything newer that stays in existance has to be focused on quality from early enough to not be defined by path dependence problems and bad choices like those 3.

by capitalhilbilly

4/28/2026 at 9:07:28 PM

Given that github is imploding under a lot of load, everyone leaving github for something else, actually makes github better.

by latchkey

4/29/2026 at 12:00:38 AM

Ah, you assumed I meant SaaS GitLab. I meant the self-hosted version. I would never host our source code on a remote service.

by gtech1

4/29/2026 at 12:06:48 AM

Why not?

by latchkey

4/29/2026 at 1:48:08 PM

Because I don't trust someone else to not train or steal our source code, or, even legally, introduce some silly cause after we are invested/locked into their infra, that allows them to do whatever with our property.

And on equal footing, I trust our security more than theirs. Case in point.

by gtech1

4/29/2026 at 10:44:28 AM

Me and my friends call it CveLab because there was a time where there was a critical security update every week or multiple times a week.

by himata4113

4/28/2026 at 9:36:09 PM

just git

by TZubiri

4/28/2026 at 6:01:47 PM

.... git?

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.

by chucky_z

4/28/2026 at 6:21:33 PM

You probably meant Forgejo. Codeberg is a Forgejo instance exclusive for FOSS projects.

by debugnik

4/28/2026 at 6:05:06 PM

i want what github offers.

by latchkey

4/28/2026 at 6:07:12 PM

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

by heliumtera

4/28/2026 at 6:10:21 PM

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

by latchkey

4/28/2026 at 6:18:03 PM

GitHub launched in 2008, so that seems unlikely?

by necubi

4/28/2026 at 6:58:10 PM

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

by seanclayton

4/28/2026 at 7:07:13 PM

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

by latchkey

4/28/2026 at 10:41:45 PM

i just deleted my account of 2008. github sucks

by sitzkrieg

4/29/2026 at 8:33:32 AM

Why do they need to stir up needless fear by using words like "BREAKING", "unauthorized access", or "millions of repositories" about the vulnerability that they caught before it was exploited in their X.com?

https://x.com/wiz_io/status/2049153209982140718

by baccatore

4/29/2026 at 4:09:28 PM

Basically every single GitHub Enterprise Server deployment is still vulnerable to this bug. that is tens of thousands of appliances containing incredibly sensitive code.

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.

by semiquaver

4/29/2026 at 11:01:43 AM

None of that is inaccurate? GitHub got lucky it was Wiz fuzzing them not state-sponsored agents?

by philipwhiuk

4/30/2026 at 12:37:00 PM

Graphite will soon be an alternative!

by fire2dev

4/28/2026 at 9:40:21 PM

Another tour de force from Wiz, and a watershed moment in AI tooling enabling RE and compromise discovery.

by angry_octet

4/28/2026 at 11:29:25 PM

It throws a wrench into the argument of not publishing your source because AI will more easily compromise the code.

Another data point against doing security through obscurity.

by avaer

4/29/2026 at 2:35:01 PM

Without the enterprise binaries, there is zero chance of finding this. Another win for obscurity.

by samlinnfer

4/28/2026 at 6:55:09 PM

I was impressed enough by AI finding vulnerabilities in source code, but doing it in binary executables is just amazing. This has so much potential, good and bad.

And yet another lesson to not treat data as instructions. Sanitize all user input!

by WASDx

4/28/2026 at 11:24:19 PM

Transformers were literally designed for translation.

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.

by avaer

4/28/2026 at 7:28:35 PM

Woah I wonder if they can tell if this has been exploited or not

by halger

4/28/2026 at 7:50:08 PM

My read is that this vulnerability is exploitable by an anonymous user. They absolutely have HTTP/gitprotocol logs that would indicate whether this was exploited but if it was, they won’t have logging about what actually got accessed and who did it, since the exploit was capable of standalone execution on the git servers, which would by definition be capable of evading any logging.

by semiquaver

4/28/2026 at 7:53:37 PM

This is just such an amateur hour vulnerability. Gluing strings together with no regard to what might be in them and then parsing them later...

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.

by formerly_proven

4/28/2026 at 11:50:30 PM

[dead]

by jeremie_strand

4/28/2026 at 9:25:49 PM

[dead]

by Neteam

4/28/2026 at 5:24:50 PM

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

by willworktill4pm

4/28/2026 at 6:25:38 PM

Only if they take Skype off the syllabus first.

by hnlmorg

4/28/2026 at 7:07:57 PM

private equity: hold my beer!

by xaxfixho