Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub RCE Vulnerability: CVE-2026-3854 Breakdown

wiz.io

Post reply on HN
Print view View original

91–97 of 97 posts

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

#91

Post by samlinnfer »

rvnx wrote: post #88
az226 wrote: post #75

Earlier quoted context omitted.

Lots of Unit 8200 peeps.

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 comp…

>China bad, Israel good

They're just aligning themselves with US foreign policy.

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

#92

Post by semiquaver »

baccatore wrote: post #79

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

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.

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

#93

Post by SlightlyLeftPad »

samlinnfer wrote: post #91
rvnx wrote: post #88

Earlier quoted context omitted.

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 comp…

>China bad, Israel good They're just aligning themselves with US foreign policy.

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.

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

#94

Post by huflungdung »

jfkimmes wrote: post #38

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 abstra…

[dead]

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

#95

Post by melozo »

HenriTEL wrote: post #86

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

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?

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

#97

Post by trashb »

semiquaver wrote: post #87
trashb wrote: post #83

Earlier quoted context omitted.

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

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 :(

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

Post reply on HN