CVE-2026-3854: GitHub Enterprise RCE via Git Push — Patch Now

One git push. No phishing, no lateral movement, no days-long privilege escalation chain. Just a standard push command with a crafted option value, and an attacker with any repository access on your GitHub Enterprise Server instance could execute arbitrary code as the git service user — with full access to every repo and stored secret on the box. That was CVE-2026-3854, a CVSS 8.7 vulnerability in GHES’s internal push pipeline discovered by Wiz Research on March 4, 2026 and publicly disclosed on April 28. At disclosure, 88% of self-hosted GitHub Enterprise Server instances were still running vulnerable versions.

If you’re on GitHub.com, relax — GitHub patched it the same day Wiz reported it. If your organization self-hosts GHES, check your version right now.

How It Worked: A Semicolon Was the Whole Attack

When you run git push -o key=value, GitHub’s internal proxy service (babeld) takes those push option values and builds an internal X-Stat header by concatenating them with semicolons as field delimiters. The header controls how the push is processed downstream — including what environment hooks run in and what directories they can access.

The problem: push option values were embedded verbatim. No sanitization. Semicolons in user-supplied values were treated as field delimiters, letting an attacker inject entirely new fields into a header that backend services trusted completely.

The three-injection RCE chain:

1. Sandbox bypass: Inject rails_env=development. The pre-receive hook binary has two paths — production runs hooks in a restricted sandbox; anything else runs them directly as the git service user with no isolation.
2. Hook directory hijack: Inject custom_hooks_dir=/attacker-controlled/path. The system now looks for hooks wherever the attacker says.
3. Path traversal to execution: Inject a crafted repo_pre_receive_hooks entry with ../../../ sequences. When the push triggers the pre-receive phase, the binary at the traversal destination executes as the git user.

All three injections. One push command. Standard git client. GitHub’s own post-mortem describes the fix as percent-encoding semicolons in push option values — a literal ; becomes %3B and can no longer break the field structure.

Are You Affected?

This depends entirely on how you host GitHub.

• GitHub.com: Patched March 4, 2026 — the same day as discovery. You’re safe.
• GitHub Enterprise Cloud: Patched. No action needed.
• Self-hosted GitHub Enterprise Server (GHES): Check your version against the table below.

GHES Release Line	First Safe Version
3.14.x	3.14.24
3.15.x	3.15.19
3.16.x	3.16.15
3.17.x	3.17.12
3.18.x	3.18.6
3.19.x	3.19.3
3.20.x	3.20.0 (all)

To find your version: open the admin console and check the footer, or SSH to the GHES admin account and run ghe-version. Anything below the thresholds in the table is still vulnerable.

What to Do Right Now

1. Upgrade immediately. All release lines through 3.14 have patched versions available. Follow the official GHES upgrade guide.
2. Review audit logs. Check /var/log/github-audit.log for push operations containing semicolons in push option values — that’s your indicator of exploitation attempts.
3. Rotate credentials if in doubt. Can’t confirm your instance was unexploited before patching? Treat it as compromised. Rotate all tokens, SSH keys, and secrets stored on or accessible from the GHES host.
4. Check for anomalous processes. Look for unexpected processes spawned from the git pipeline, or unexpected files in hook directories.

The Bigger Problem: Your Developer Toolchain Is the Target

CVE-2026-3854 didn’t exploit your application code. It exploited the infrastructure you use to write and ship it. Push options — a feature most developers use on autopilot for CI/CD triggers or skip-CI flags — turned out to be user-controlled input flowing directly into privileged server-side processing. Nobody treated them as an injection surface because nobody thought of them that way.

This isn’t isolated. The same threat actor (TeamPCP) that backdoored a Checkmarx Jenkins plugin last week operates in the same space: developer toolchain infrastructure. npm packages, Jenkins plugins, git push pipelines — if it’s part of how code gets built and shipped, it’s a target.

Wiz Research found this vulnerability using AI-assisted reverse engineering on GitHub’s closed-source babeld binary. When AI can surface critical flaws in proprietary production binaries that fast, the assumption that closed-source equals safer is finished. Wiz’s full technical breakdown is worth reading if you want to understand what that research looks like in practice.

GitHub’s response was exemplary — same-day patch on GitHub.com, responsible disclosure, a clear post-mortem. The 88% unpatched rate isn’t on GitHub. It’s a reminder that git infrastructure doesn’t get the patch scrutiny it deserves. It should.