Vulnerability overview | Image: Wiz Research
Wiz Research has unveiled a critical security flaw (CVE-2026-3854) within GitHub’s internal git infrastructure. The vulnerability, remarkably simple to execute but devastating in scope, allowed any authenticated user to achieve Remote Code Execution (RCE) on GitHub’s backend servers using nothing more than a standard git client.
The impact was felt across both the public GitHub.com platform and GitHub Enterprise Server (GHES), potentially exposing millions of private repositories to unauthorized access.
The flaw lies in a specialized internal protocol used to pass metadata between GitHub’s backend services, specifically through a component called the X-Stat header. When a user initiates a git push, the request travels through a proxy (babeld) to an authentication service (gitauth), and finally to an RPC server (gitrpcd) that handles the environment setup.
The report notes a critical breakdown in trust between these layers, “gitrpcd performs no authentication of its own – it trusts babeld completely and treats every field in the X-Stat header as authoritative”.
The X-Stat header uses semicolons to separate different security-critical fields. However, researchers found that babeld failed to sanitize semicolons within “git push options”—arbitrary strings that users can provide during a push. By inserting a semicolon into a push option, an attacker could “break out” of the intended field and inject new, malicious fields into the header.
The research team successfully chained multiple injected fields to bypass security controls. By manipulating the rails_env field, they forced GitHub’s pre-receive hook binary to switch from a secure production sandbox to an isolated “non-production” execution path.
Combining this with path traversal payloads, the researchers were able to execute arbitrary binaries directly on the server. The report details the success of this chain, “A single git push command was enough to exploit a flaw in GitHub’s internal protocol and achieve code execution on backend infrastructure”.
On GitHub.com, the consequences were even more profound due to the platform’s multi-tenant nature. Once code execution was achieved, the researchers landed on shared storage nodes as the git user—a high-privilege account designed to manage repository operations across the entire node.
“Compromising this user meant we could read any repository on the node, regardless of which organization or user owned it,” the Wiz team explained. Their data indicated that millions of public and private repository entries were accessible from these compromised nodes.
The researchers utilized AI-augmented reverse engineering tools, specifically IDA MCP, to rapidly analyze the compiled binaries and reconstruct the internal protocols. Wiz Research characterized this as a major shift, “Notably, this is one of the first critical vulnerabilities discovered in closed-source binaries using AI, highlighting a shift in how these flaws are identified”.
GitHub acted swiftly, mitigating the issue on GitHub.com within six hours of the initial report. While no action is required for public cloud users, GitHub Enterprise Server customers must prioritize immediate upgrades.
| Component | Vulnerable Versions | Fixed Version |
| GitHub Enterprise Server |
<= 3.19.1 |
3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, 3.19.3 |
As of the latest data, roughly 88% of GHES instances remain vulnerable. Administrators are urged to upgrade to version 3.19.3 or later immediately to patch CVE-2026-3854.
Support Our Threat Intelligence
If you find our CVE report and cybersecurity news helpful, consider supporting our work.