GitHub RCE: Crafted 'git push' Commands Compromised Backend Servers

CVE-2026-3854: An X-Stat header injection vulnerability in GitHub enabled remote code execution via a single push operation. Approximately 88% of Enterprise in…

On April 28, 2026, Wiz Research disclosed a critical vulnerability affecting GitHub.com and GitHub Enterprise Server (GHES) that allowed for remote code execution (RCE) via a single crafted git push operation. The flaw, tracked as CVE-2026-3854, stems from a lack of sanitization for the ';' delimiter within the internal X-Stat header. This vulnerability effectively turned any account with push permissions into a total compromise vector, posing a significant threat to self-hosted instances. Discovered using AI-assisted reverse engineering on closed-source binaries, the flaw highlights evolving risks within the infrastructure powering the global software industry.

Key Takeaways

The vulnerability exists in the unsanitized passing of git push options to the internal X-Stat header, where the ';' character acts as a delimiter, allowing attackers to inject arbitrary fields using last-write-wins semantics.
On GitHub Enterprise Server, the exploit chain results in unsandboxed RCE as the 'git' user, providing full access to the filesystem and internal secrets; 88% of instances were estimated to be vulnerable at the time of disclosure.
On GitHub.com, the attack allowed code execution on shared storage nodes, creating a cross-tenant risk for millions of public and private repositories hosted on the same infrastructure.
The flaw was identified through AI-assisted reverse engineering, demonstrating how automated analysis of closed-source binaries can uncover critical vulnerabilities in core software development infrastructure.

Exploit Chain on GitHub Enterprise Server

"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 reported. On GitHub Enterprise Server, this single operation leads to a complete server compromise. As GitHub CISO Alexis Wales explained, "By chaining several injected values together, the researchers demonstrated that an attacker could override the environment the push was processed in, bypass sandboxing protections that normally constrain hook execution, and ultimately execute arbitrary commands on the server."

The exploit chain requires three successive injections into the X-Stat header: overwriting the rails_env field to bypass pre-receive hook sandboxing, modifying custom_hooks_dir to redirect the hook directory, and injecting repo_pre_receive_hooks to perform path traversal and execute arbitrary commands as the 'git' user.

With unsandboxed code execution as the 'git' user, an attacker gains full control over the instance, including read/write access to the filesystem and visibility into internal service configurations. According to researchers, this scenario exposes the entire server surface—from source code to shared secrets—without requiring any initial administrative privileges beyond standard push access to a repository.

"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" — Sagi Tzadik, Wiz security researcher

How a Semicolon Compromised Internal Protocols

The core of the defect lies in how GitHub's git pipeline processes user-supplied push options. The babeld service directly copies these values into the X-Stat header without sanitizing the ';' character, which serves as a delimiter for key-value pairs in the internal protocol. Because the downstream parser applies last-write-wins semantics, any push option containing a semicolon allows the injected value to break out of its designated field and silently overwrite subsequent security keys. As Wiz Research noted, "When multiple services written in different languages pass data through a shared internal protocol, the assumptions each service makes about that data become a critical attack surface."

This discrepancy between the assumptions of the service generating the header and the component consuming it transforms the X-Stat header from a simple metadata vehicle into an injection channel. The failure to validate user input before passing it between services written in different languages allows for the alteration of backend processes that manage the entire code ingestion pipeline.

GitHub.com and Cross-Tenant Risks on Shared Nodes

The same vulnerability affected GitHub.com, where the exploit enabled code execution on storage nodes shared across multiple tenants. Researchers confirmed that millions of public and private repositories belonging to other users and organizations were accessible on compromised nodes, elevating the risk from an isolated incident to a potential mass cross-tenant exposure.

GitHub mitigated the flaw on its cloud services on March 4, 2026, within six hours of the report from Wiz. The company reproduced the vulnerability internally in approximately 40 minutes and released a fix by 19:00 UTC the same day. In an official statement, the platform noted: "GitHub greatly appreciates the collaboration, professionalism, and partnership that Wiz has shown throughout this process. A finding of this caliber and severity is rare, earning one of the highest rewards available in our Bug Bounty program."

Despite the rapid response, the shared nature of the infrastructure makes this vector particularly dangerous for data segregation between independent tenants.

Mitigation and Security Recommendations

For organizations running GitHub Enterprise Server, the immediate priority is to apply the updates released by GitHub, given that approximately 88% of installations were still vulnerable at the time of public disclosure.

It is also necessary to restrict push permissions to only essential accounts, as any authenticated user with these rights can trigger the exploit chain with a single command.

Security teams should analyze audit logs for anomalous git push operations containing unusual push options, ensuring that mapped paths correspond to legitimate sessions.

Finally, organizations should consider isolating GHES instances within restricted network segments and verifying the integrity of internal secret backups, as a total server compromise exposes the entire repository of code and credentials.

AI-Assisted Reverse Engineering: A New Frontier for Pipeline Security

The discovery of CVE-2026-3854 marks a paradigm shift in vulnerability research for enterprise-level closed-source infrastructure. Wiz Research utilized AI-assisted reverse engineering tools to analyze proprietary binaries within GitHub's git pipeline, identifying the lack of input sanitization without access to the original source code.

This approach demonstrates that central code management platforms—even those not relying on open-source components—expose attack surfaces that can be analyzed automatically at scale. For the industry, the implication is that protecting development pipelines now requires a threat modeling approach that considers not only public dependencies but also the robustness of internal protocols orchestrating backend services and how they interpret data in transit.

The CVE-2026-3854 case proves that the security of code hosting platforms depends as much on the integrity of internal protocols as it does on the quality of externally visible code. When services written in different languages exchange data via shared formats, misaligned assumptions regarding sanitization and parsing become systemic flaws. For enterprises, the message is clear: the software supply chain begins long before the final commit—it begins with how the platform itself ingests a single git push.

Frequently Asked Questions

Did this vulnerability affect GitHub.com users without Enterprise instances?

Yes. In addition to GHES, the flaw impacted GitHub.com's cloud infrastructure, allowing code execution on shared storage nodes. Although GitHub mitigated the issue on March 4, 2026, researchers confirmed that millions of public and private repositories from other users were accessible on compromised nodes, expanding the risk beyond a single tenant.

Why does the vulnerability have different CVSS scores between GitHub and the NVD?

GitHub assigned the vulnerability a score of 8.7 using CVSS version 4.0, while the National Vulnerability Database (NVD) reports a value of 8.8 based on version 3.1. This discrepancy reflects different calculation methodologies and impact contextualization between the vendor and public databases, though both scores place the flaw firmly in the high-severity range.

Was any malicious exploitation detected prior to public disclosure?

According to reports from GitHub and Wiz, there is no evidence of malicious exploitation outside of the testing conducted by researchers. All detected occurrences were mapped to Wiz's verification sessions, with no other users or accounts involved. However, it remains unknown if any public proofs-of-concept or undetected active attacks existed prior to April 28, 2026.

Information verified against cited sources and updated at the time of publication.