Wiz found an RCE in GitHub's git-push pipeline. The patch shipped in six hours.

Wiz Research disclosed CVE-2026-3854 on April 28: a CVSS 8.7 remote code execution bug in GitHub’s internal git-push pipeline. A single git push with maliciously crafted push options bypassed sandbox restrictions and executed attacker-controlled commands inside babeld, gitauth, and gitrpcd, the binaries GitHub runs for every push it accepts. GitHub.com patched the bug within six hours of report. The Enterprise Server fix took six days. The disclosure window after that lasted seven weeks.

That last number is the part to focus on. Wiz says 88% of internet-facing GitHub Enterprise Server instances were still vulnerable on the day of disclosure.

What the bug actually is

The vulnerable code path was an HTTP-style header GitHub uses internally, called X-Stat, that gets passed between babeld (the git proxy that fronts pushes), gitauth (the auth-checking service), gitrpcd (the RPC server that executes git operations), and the pre-receive hook binary. The header is supposed to carry per-push metadata. It used semicolons as field separators without escaping the field values.

If a push option contained an unescaped semicolon, the value bled into the next field. Wiz’s writeup demonstrates that an attacker-controlled push option could inject a forged authentication context, and from there execute commands on the server side. This is the classic “trust the inputs, then concatenate them into a structured header” bug the application-security industry has been writing the same blog post about for 20 years. It just hadn’t been spotted yet inside GitHub’s compiled Go binaries.

The Wiz team wrote that AI did much of the legwork: “Using AI, we rapidly analyzed GitHub’s compiled binaries, reconstructed internal protocols, and systematically identified where user input could influence server behavior.” Wiz is making that point on purpose. Reverse-engineering compiled servers used to be the limiting factor on this class of research; it isn’t anymore.

The timeline is the news

Wiz reported the bug on March 4, 2026. GitHub deployed a fix to github.com the same day, within six hours. The Enterprise Server patch shipped on March 10 in supported branches.

Then nothing was public until April 28. That’s a 55-day disclosure window during which github.com customers were safe but GHES customers, who self-host on their own infrastructure, were on their own to apply the patch. Wiz’s scan on disclosure day found that 88% of GHES instances reachable from the public internet were still on the vulnerable version. That number is staggering, but it’s also the GHES patching baseline: Enterprise customers run on quarterly cadence, often slower, and a March release lands inside an organization roughly never within the same week.

GitHub hasn’t published an exploitation count. Wiz says it found no in-the-wild exploitation, which is consistent with responsible disclosure but isn’t a permanent guarantee. Now that the writeup is public with proof-of-concept structure, anyone who hasn’t patched is in a race against the next person who reads the blog post.

What it doesn’t break

The bug is exploitable through git push, not browser navigation. A user reading the GitHub web UI couldn’t trigger it. A repo owner couldn’t be silently exploited by a viewer. The attacker has to push, and the push has to include the crafted option set. That narrows the threat to anyone who can push to any repo on a vulnerable instance, which on a public github.com is the entire internet, but on a private GHES is the company’s own developers plus any external collaborators with push access.

The other thing it doesn’t break is the merits of the fix. The github.com response time is what fast incident response actually looks like, and Wiz’s post says so explicitly. The story is the long tail behind it.

This lands in the same week as Mitchell Hashimoto’s decision to pull Ghostty off GitHub over uptime complaints. The two issues aren’t connected, but together they make for an awkward few days for the platform’s reliability narrative, on top of GitHub’s own availability update acknowledging a rough Q1 for Actions and Codespaces.

What this means for you

If you use github.com, you’re already patched. Nothing to do. Move on.

If you run GitHub Enterprise Server, check your version against the March 10 patch advisory right now. If you’re on anything older than the March release, you have a CVSS 8.7 RCE that’s now publicly described. The proof-of-concept isn’t shipped, but the field-injection pattern is. Schedule the upgrade today; there’s no reason to defer it past the next maintenance window.

If you’ve been holding the line on letting external contributors push to private repos on GHES, the audit you just rationalized is now overdue. Pin a follow-up on patch latency for GHES inside your team’s own SLA review. The lesson Wiz makes explicit, and that the March ASP.NET out-of-band incident drove home a week ago, is that fast vendor patching only matters as much as your patching cadence does.