A critical remote code execution (RCE) vulnerability tracked as CVE-2026-3854 has been disclosed in GitHub’s internal git infrastructure. Discovered by Wiz researchers using AI-augmented reverse engineering, the flaw could have allowed any authenticated user to compromise backend servers, access millions of private repositories, and achieve cross-tenant data exfiltration at scale.
GitHub received the vulnerability report on March 4, 2026, validated it within hours, and deployed a fix to GitHub.com by 7:00 p.m. UTC the same day. However, as of the time of public disclosure, Wiz data indicated that 88% of GitHub Enterprise Server (GHES) instances remained unpatched. Administrators of self-hosted GHES deployments are urged to apply the patch immediately.
How the Vulnerability Was Discovered
The Wiz research team leveraged IDA MCP for automated reverse engineering, enabling rapid reconstruction of GitHub’s internal protocols across compiled binaries — an analysis that would have been prohibitively time-consuming through manual methods. This marks one of the first publicly documented critical vulnerabilities in closed-source binaries to be uncovered using AI tooling at scale, signaling a meaningful shift in the methodology for vulnerability research in opaque, multi-service architectures.
Technical Details: Header Injection via Last-Write-Wins Parsing
CVE-2026-3854 stems from an improper neutralization of special elements (CWE-77) in how GitHub’s internal service gitrpcd parsed the X-Stat HTTP header. Because gitrpcd used last-write-wins semantics when processing the header, an attacker could inject new key-value fields simply by embedding a semicolon followed by a field name and value.
Security-critical fields — including rails_env, custom_hooks_dir, and repo_pre_receive_hooks — were all overridable through this single injection vector. The escalation to full RCE required chaining three injected fields together:
- Setting
custom_hooks_dirto an attacker-controlled path - Enabling
repo_pre_receive_hooksto execute custom scripts on push - Triggering a git push event to invoke the malicious hook
The entire exploit required no privilege escalation, no special tooling, and no zero-day dependencies — just a standard git client and a valid GitHub account.
Impact: Cross-Tenant Repository Access
On GitHub.com, Wiz initially found that the custom hooks code path was inactive by default, but discovered that a boolean enterprise_mode flag in the X-Stat header was equally injectable, enabling the full RCE chain. Upon achieving RCE on GitHub.com’s shared storage nodes, Wiz confirmed that the git service user had filesystem access to millions of repositories belonging to other users and organizations — representing a severe cross-tenant data exposure risk.
GitHub’s forensic investigation confirmed no malicious exploitation occurred before the patch was deployed. GitHub Enterprise Cloud and GitHub.com users require no action, as the fix was applied server-side. However, GHES administrators must apply the patch manually to their self-hosted instances.
Recommended Actions for GHES Administrators
- Apply the GHES security patch released by GitHub as of March 2026 immediately
- Audit
/var/log/github-audit.logfor push operations containing unusual special characters in push option values as potential indicators of prior exploitation - Review access logs for the gitrpcd service for anomalous
X-Statheader values - Restrict network-level access to GHES management interfaces where possible
- Monitor for unauthorized repository clones or access patterns across tenants
Broader Implications for AI-Assisted Vulnerability Research
The discovery methodology is nearly as significant as the vulnerability itself. By automating reverse engineering of closed-source binaries with AI tooling, Wiz was able to rapidly identify protocol-level flaws that would have remained hidden for much longer under traditional analysis. This signals a new paradigm: attackers and defenders alike will increasingly use AI-augmented analysis to find vulnerabilities in opaque, proprietary systems.
Security teams managing large estates of third-party and internally developed binary software should begin evaluating AI-assisted reverse engineering capabilities as part of their proactive vulnerability management programs. The era in which closed-source code provided a meaningful barrier to vulnerability discovery is rapidly ending.