One git push. Full server takeover. Here’s the full technical breakdown of CVE-2026-3854 — one of the most severe vulnerabilities in GitHub’s history.

The Vulnerability Explained

CVE-2026-3854 was a critical RCE (Remote Code Execution) vulnerability in GitHub Enterprise Server and GitHub.com, discovered by Wiz Research using AI-assisted reverse engineering. The CVSS score was 8.8 — and for good reason.

The vulnerability lived in GitHub’s babeld service, which handles git push operations. Here’s the problem: when you run git push with push options (like -o foo=bar), babeld copies those values directly into an HTTP header called X-Stat. But it doesn’t sanitise semicolons.

So a push option value like foo=bar;evil — the semicolon breaks out of the field and lets the attacker inject entirely new header fields. Those fields hit services that execute system commands. And that’s how you go from a git push to remote code execution.

No zero-day. No special tooling. No commit access to sensitive repos needed. Just a semicolon.

Exploitation Chain

Here’s how the attack worked:

1. Attacker creates any repository on the target GitHub instance (even a fresh one)
2. Attacker pushes with a malicious push option value containing a semicolon
3. babeld copies the unsanitized value to the X-Stat HTTP header
4. The semicolon breaks the header field, allowing header injection
5. Injected headers reach backend services that execute system commands
6. RCE achieved — full server compromise

GHES vs GitHub.com Impact

On GitHub Enterprise Server (GHES):

• Full appliance compromise
• Every repository exposed
• Every secret and credential is accessible
• Internal network access
• Every self-hosted GitHub instance was vulnerable

On GitHub.com (the SaaS version):

• RCE on shared storage nodes
• Cross-tenant data access — meaning other customers’ repositories
• This is the nightmare scenario for multi-tenant cloud providers

AI-Assisted Discovery

This wasn’t found by a human researcher manually poking at the code. Wiz used IDA MCP (an AI-powered reverse engineering tool) to analyse closed-source GitHub binaries. The AI found what human researchers had missed for years.

This represents a shift in bug bounty research: AI-assisted reverse engineering can find critical vulnerabilities in closed-source software that manual approaches missed.

Patch Status — 88% Unpatched

The worst part of this story: 88% of GitHub Enterprise Server instances were still unpatched 7 weeks after disclosure.

GitHub.com was patched on March 4, 2026 — the same day the report was submitted. Fast response. But self-hosted GHES? Organisations were slow to patch.

This is the classic enterprise patching problem: GHES instances are often managed by IT teams with change management processes, not security teams pushing emergency patches.

How to Check If You’re Vulnerable

If you run GitHub Enterprise Server, check your version now:

curl -s https://your-ghes-hostname/api/v3/enterprise/grid | grep version

Fixed versions:

• 3.14.25
• 3.15.20
• 3.16.16
• 3.17.13
• 3.18.7
• 3.19.4

If you’re on an older version, update immediately. This is as critical as it gets.

Wrapping Up

CVE-2026-3854 is a reminder that the most dangerous vulnerabilities often come from the simplest injection points. A semicolon in a git push option — something developers use every day — led to full server compromise.

If you run GHES, patch now. If you use GitHub.com, you’re covered—but stay aware of the vulnerability class.

Share this with every GitHub admin you know.

Links:

• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-3854
• Wiz Research: https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854

#cybersecurity #ethicalhacking #infosec #cve20263854 #github #rce #pentesting #bugbounty