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
jfkimmes
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.
show comments
jcims
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.
show comments
saghm
> 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.
show comments
baccatore
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?
> GitHub Enterprise Server customers should upgrade immediately - at the time of this writing, our data indicates that 88% of instances are still vulnerable
88% of on-prem customers haven't applied a critical security fix from 7 weeks ago, that seems ... bad.
show comments
angry_octet
Another tour de force from Wiz, and a watershed moment in AI tooling enabling RE and compromise discovery.
show comments
latchkey
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?
show comments
WASDx
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!
show comments
halger
Woah I wonder if they can tell if this has been exploited or not
show comments
formerly_proven
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.
show comments
willworktill4pm
GitHub case will be thought in schools how to screw up almost monopolistic position in the market in couple years. This is beyond bonkers.
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
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.
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.
> 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.
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
> 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.
Another tour de force from Wiz, and a watershed moment in AI tooling enabling RE and compromise discovery.
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?
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!
Woah I wonder if they can tell if this has been exploited or not
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.
GitHub case will be thought in schools how to screw up almost monopolistic position in the market in couple years. This is beyond bonkers.