GitHub RCE Flaw CVE-2026-3854 Exposed Millions of Repos

A critical remote code execution (RCE) vulnerability in GitHub’s internal git infrastructure, CVE-2026-3854 (CVSS: 8.7), that allowed any authenticated user to compromise GitHub’s backend servers using nothing more than a standard git push command with a crafted push option.

CVE-2026-3854 is an improper neutralization of special elements vulnerability in GitHub Enterprise Server’s internal git push pipeline. During an git push operation, user-supplied push option values were incorporated into internal service headers, specifically the X-Stat header without adequate sanitization.

Because the internal metadata format used a semicolon (;) as a field delimiter, and because that same character could appear freely in user input, attackers could break out of the intended field boundary and inject arbitrary metadata fields that downstream services treated as fully trusted.

CVE-2026-3854: GitHub RCE Vulnerability

The vulnerability affected GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, GitHub Enterprise Cloud with Enterprise Managed Users, and all supported versions of GitHub Enterprise Server.

Security team discovered it through AI-augmented reverse engineering using IDA MCP, marking one of the first critical vulnerabilities in closed-source binaries uncovered with AI tooling.

The exploitation chain is deceptively simple, requiring no special tooling beyond a standard git client. The internal git push pipeline routes every push through three key services: babeld (the git proxy entry point), gitauth (the authentication and policy service), and gitrpcd (an internal RPC server that inherits the X-Stat header as fully trusted).

babeld copies push option values directly into the X-Stat header verbatim, including any semicolons. Because downstream parsers split on with last-write-wins semantics, an injected field appearing later in the header silently overrides its legitimate counterpart. The team confirmed this both through static binary analysis and live packet capture on a GHES instance.

The RCE chain strings three injected fields together:

Step 1 – Sandbox bypass: Inject a non-production rails_env value, switching the pre-receive hook binary from a sandboxed execution path to an unsandboxed, direct-execution path.
Step 2 – Hook directory hijack: Inject custom_hooks_dir to redirect where the binary looks for hook scripts.
Step 3 – Path traversal to arbitrary binary: Inject repo_pre_receive_hooks with a crafted hook entry containing a path traversal sequence, causing the binary to resolve and execute an arbitrary file on the filesystem as the git service user.

The git service user has broad filesystem access to every repository hosted on the affected node by design, meaning successful exploitation on GitHub.com landed attackers on shared multi-tenant storage nodes housing millions of repositories across different organizations.

GitHub.com vs. GitHub Enterprise

The same injection mechanism worked on both platforms, but required one additional injected field for GitHub.com. On GHES, the enterprise_mode flag in the X-Stat header defaults to true, keeping the custom hooks code path active at all times.

On GitHub.com, it defaults to false, but since the flag itself could be injected via the same mechanism, researchers flipped it with a single additional injection to achieve full RCE on GitHub.com’s shared infrastructure.

Platform	Default Exploitable	Cross-Tenant Impact
GitHub Enterprise Server	Yes (enterprise_mode=true by default)	Full server compromise, all hosted repos
GitHub.com	Requires one extra field injection	Millions of repos on shared storage nodes

Remediation

GitHub’s response was rapid and methodical. After reporting the vulnerability on March 4, 2026 by wiz researchers, GitHub validated and reproduced it internally within 40 minutes, deployed a fix to GitHub.com at 7:00 PM UTC, less than two hours after confirmation, and completed a forensic investigation confirming zero exploitation by any party.

The fix ensures that user-supplied push option values are properly sanitized before they are embedded in the X-Stat header. For GitHub Enterprise Server, patches were released across all supported versions:

GHES 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, and 3.20.0 or later

Despite public disclosure, 88% of GHES instances remain unpatched at the time of writing. GHES administrators should upgrade immediately and review /var/log/github-audit.log for any push operations containing semicolons in push options as an indicator of attempted exploitation.

This vulnerability exposes a systemic risk pattern in multi-service architectures. When multiple services written in different languages share a common internal protocol, each service’s implicit trust assumptions become a combined attack surface.

In this case, one service assumed push option values were safe to embed verbatim; another assumed all X-Stat fields were authoritative; and the pre-receive hook assumed the rails_env variable could only hold a production value in production. Each assumption was reasonable in itself, but collectively catastrophic.

The research also demonstrates that AI-augmented reverse engineering can now uncover critical vulnerabilities in closed-source, compiled binaries at speeds previously impractical for human-only analysis. As these tools mature, security teams should anticipate a higher velocity of complex, cross-component vulnerability discoveries.