CVE-2026-3854: One git push RCE in GitHub, 88% of GHES instances…

Wiz Research disclosed a critical RCE in GitHub Enterprise Server exploitable with a single git push command. GitHub patched GitHub.com within two hours, but 88% of self-hosted GHES instances remained vulnerable at disclosure.

On March 4, 2026, Wiz Research disclosed a critical remote code execution vulnerability to GitHub, later cataloged as CVE-2026-3854, that lets any authenticated user with push access take full control of a GitHub Enterprise Server with a single command. GitHub validated the report in 40 minutes and deployed the fix to GitHub.com in under two hours, but the figure that defines real-world risk is different: according to Wiz, 88% of self-hosted GHES instances remained vulnerable at the time of disclosure.

Key takeaways

CVE-2026-3854 carries a CVSS 4.0 score of 8.7 (HIGH) assigned by GitHub as CNA, and 8.8 in the NVD CVSS 3.1 assessment: CWE-77, command injection.
Exploitation requires a single git push -o with a crafted value that exploits the lack of semicolon sanitization in the internal X-Stat header.
GitHub.com was patched by March 4, 2026; on self-hosted GHES the vulnerability leads to full server compromise, while on GitHub.com it enabled cross-tenant access to millions of repositories.
Wiz used AI-augmented tooling, specifically IDA MCP for automated reverse engineering of closed-source binaries, cutting timelines previously deemed "too costly."

How the exploitation chain works: from internal header to server control

The mechanism originates in babeld, the component that handles git push operations: user-supplied push option values are copied directly into the internal X-Stat header without sanitizing the ; character. Wiz confirmed the vulnerability via packet capture on a live GHES instance, documenting how the semicolon delimiter allows injection of additional fields into the parsing map, which follows a "last-write-wins" semantic.

The exploitation chain unfolds in three stages. First, the injection bypasses pre-receive hook sandboxing by redefining the execution environment. Second, the custom_hooks_dir directory is redirected. Third, the repo_pre_receive_hooks path is manipulated via path traversal to achieve unsandboxed code execution as the git user. Sagi Tzadik, Wiz researcher, stated: "With unsandboxed code execution as the git user, we had full control over the GHES instance, including filesystem read/write access and visibility into internal service configuration."

On GitHub.com the same chain allowed code execution on shared storage nodes, with verified access to millions of public and private repositories belonging to other users and organizations. The attack vector requires no administrative privileges: any account with push permission suffices.

The AI that reads the binary no one can see: the Wiz method

The methodological differentiator in this research is the use of automated reverse engineering on proprietary code. Wiz employed IDA MCP, a plugin that integrates language models into the IDA Pro disassembler, to analyze GitHub's closed-source binaries in timeframes described as "previously impractical." The company's published statement is precise: "By leveraging AI-augmented tooling—particularly automated reverse engineering using IDA MCP—we were able to do what was previously too costly."

The paradox is clear: the same tool that accelerates vulnerability discovery can also accelerate offensive analysis of software that does not distribute source code. For proprietary software vendors, this represents a shift in the threat landscape. Binary secrecy no longer constitutes a predictive barrier against systematic analysis.

GitHub's response and the patching gap in self-hosted instances

Alexis Wales, GitHub CISO, confirmed the operational timeline: the Wiz report arrived through the Bug Bounty program on March 4, 2026; internal validation took 40 minutes; the fix was deployed to GitHub.com by 7:00 p.m. UTC, less than two hours after validation. Wales also stated that every occurrence detected in logs corresponds to the researchers' testing activity, with "no customer data accessed, modified, or exfiltrated."

The discrepancy between cloud and self-hosted emerges in the numbers. While GitHub.com was fixed the same day, customer-managed GHES instances depend on patches released in specific versions. According to the NVD record, affected versions and their fixes include the 3.14, 3.15, 3.16, 3.17, 3.18, and 3.19 branches, with patch builds indicatively in the .24/.25 series or later depending on the branch. Wiz reports that 88% of scanned GHES instances remained vulnerable at the time of the research publication.

The dossier does not specify the absolute denominator of total instances, the exact number of patched installations, nor quantify the Bug Bounty reward, described only as "one of the highest rewards."

What to do now

Verify the installed GitHub Enterprise Server version and compare it with the patched builds indicated in advisory GHSA-64fw-jx9p-5j24; update to a fixed version if the instance falls within the affected series.
Audit access logs to identify git push commands with unusual -o options, particularly values containing delimiter characters, mapping them against Wiz's documented testing activity.
Review push access policies to limit the privilege to users with documented operational need, reducing the surface of accounts that could theoretically trigger the exploitation chain.
Monitor official GitHub Security channels and the NVD feed for CVE-2026-3854 for potential metric revisions or extensions of the affected version range.

"A single git push command was enough to exploit a flaw in GitHub's internal protocol and achieve code execution on backend infrastructure" — Wiz Research

Frequently asked questions

Is GitHub.com still at risk?
No. The cloud platform was fixed on March 4, 2026, within two hours of report validation. Residual risk applies exclusively to unpatched self-hosted GHES instances.

Is admin access required to exploit the vulnerability?
No. Any authenticated user with push permission on a repository can trigger the chain, as confirmed by the CVSS vector description with PR:L (privileges required low).

Is the use of AI in the discovery verified or a marketing narrative?
Wiz explicitly states the use of IDA MCP for automated reverse engineering. The dossier does not establish whether the vulnerability would have been discoverable without AI tooling, nor whether analysis had already begun manually. The methodology claim is drawn from the primary source without independent corroboration of operational detail.

The lesson from CVE-2026-3854 is not only technical: an internal protocol with implicit trust between components, presumably designed to isolate multi-tenant environments, proved vulnerable to an elementary injection. The use of artificial intelligence to deconstruct proprietary binaries introduces a speed variable that vendor security programs will need to integrate into their risk projections.

Information verified against cited sources and current as of publication.

Sources

Sources and references