What if the command you run a hundred times a day could execute arbitrary code on GitHub's servers?

On March 4, 2026, researchers at Wiz discovered something terrifying: a single git push with crafted options could achieve remote code execution on GitHub.com. No special tools. No zero-day exploit kit. Just a standard git client and a semicolon.

This is CVE-2026-3854. CVSS 8.7. And it sat in GitHub's internal infrastructure for years.

The Bug: A Semicolon in the Wrong Place

GitHub's git infrastructure relies on an internal proxy called babeld to handle repository operations. When you run git push -o <option>, those push option values travel straight to the server.

Here's the problem: babeld copied those values directly into a semicolon-delimited internal X-Stat header without sanitizing the semicolon character. Since semicolons were also the field delimiter, an attacker could inject additional metadata fields simply by embedding a semicolon in a crafted push option.

Think about that for a second. The delimiter character wasn't escaped. In 2026.

What This Means in Practice

Any authenticated user with push access to any repository — even one they created themselves — could execute arbitrary commands on GitHub's backend servers. The attack vector was:

  • Standard git client
  • Single git push command
  • Crafted -o option with embedded semicolon
  • Command injection into internal service headers
  • Remote code execution on shared infrastructure

GitHub.com is a multi-tenant platform where millions of repositories from different organizations share the same backend nodes. When researchers achieved code execution, they landed on a shared storage node as the git user — a service account designed with broad filesystem access to every repository on that node.

Millions of private repositories. One compromised node.

The Response: Fast, But Frustratingly Late

Credit where it's due: GitHub's response was swift. Wiz reported the issue on March 4. GitHub validated it in under two hours and deployed a fix to GitHub.com by 7:00 PM UTC the same day. A forensic investigation confirmed no prior exploitation.

But here's what stings: public disclosure was delayed until April 28 to give GitHub Enterprise Server customers time to patch. That's nearly two months where the vulnerability existed in self-hosted instances, and the broader community had no idea.

And the timing? Brutal. The disclosure dropped on the same morning GitHub's CTO published an apology for a separate incident where GitHub's merge queue silently reverted 2,092 pull requests five days earlier. Two days before that, search broke under what GitHub called a likely botnet attack. Three failures of git's trust contract in five days.

Why This Matters Beyond GitHub

GitHub hosts over 420 million repositories and serves 150 million developers. When you compromise GitHub, you don't breach one company — you breach the global software supply chain.

This vulnerability also raises uncomfortable questions about internal tooling we rarely scrutinize:

  • How many other platforms have internal proxies that blindly trust user input?
  • How often do we audit the boundary between user-facing APIs and internal services?
  • What happens when a multi-tenant platform shares backend nodes across organizations with different security requirements?

The babeld proxy wasn't some obscure edge case. It was core infrastructure. And a single missing sanitization step turned it into a remote shell.

Mitigation: Patch Now, Audit Later

GitHub Enterprise Server users should update to versions 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, or 3.19.4 immediately. GitHub.com was patched on March 4, so cloud users are protected.

For defenders more broadly, this is a reminder to:

  • Audit internal service boundaries — especially where user input crosses from public APIs to internal headers
  • Never trust delimiters without escaping or validation
  • Segment multi-tenant workloads so a single node compromise doesn't expose every tenant's data
  • Monitor for anomalous git operations, especially unusual -o push options

The Bottom Line

CVE-2026-3854 is a masterclass in how a tiny oversight — failing to escape a delimiter character — can cascade into a platform-wide compromise. The git push command is so fundamental to modern development that we don't think of it as an attack surface. We should.

Because sometimes the most dangerous exploit isn't a fancy zero-day chain. It's a semicolon, in a header, in a proxy you didn't know existed.