Critical GitHub RCE: Single Git Push Triggers Backend Code Execution

CVE-2026-3854 allows RCE on GitHub.com and GHES via a single git push. The discovery, facilitated by AI-assisted reverse engineering of closed-source binaries,…

On April 28, 2026, Wiz Research disclosed CVE-2026-3854, a critical remote code execution (RCE) vulnerability affecting both GitHub.com and GitHub Enterprise Server (GHES). An authenticated user with basic write permissions can execute arbitrary code on backend servers through a single manipulated git push, exploiting a lack of sanitization for the ";" delimiter in the internal X-Stat header. While GitHub patched its cloud environment nearly a month before disclosure, data reveals that almost 90% of on-premise instances remained exposed, turning a resolved flaw into an active supply chain risk.

Key Takeaways

A single git push using malicious push options enables RCE on GitHub.com and GHES for users with write access, requiring no victim interaction.
The flaw stems from unvalidated ";" characters in the internal X-Stat header, allowing critical parameter injection via last-write-wins logic.
On GitHub.com, the vulnerability created cross-tenant risks for millions of public and private repositories hosted on shared storage nodes.
GitHub secured the cloud environment on March 4, 2026, within six hours of the report; however, nearly 88% of GHES instances remained vulnerable as of April 28.

"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

X-Stat and the Forgotten Delimiter: Anatomy of the Flaw

The core of the defect lies within babeld, the component responsible for routing git operations across GitHub’s infrastructure. When a user submits a push with custom options—legitimate parameters typically used to trigger CI configurations or hooks—babeld inserts them directly into an internal X-Stat header. Critically, it fails to sanitize or encode the semicolon character. Because the multi-service protocol uses ";" as a field delimiter, an attacker can inject arbitrary key-value pairs. Downstream services interpret these as legitimate parameters, overwriting original values using a last-write-wins priority.

The X-Stat header serves as a metadata channel between services written in various languages, with each module assuming the content has already been validated. This lack of cross-validation transforms an auxiliary feature into an attack vector capable of altering the hook execution engine's behavior. The injection does not require administrative privileges; write access to a single repository—a standard permission for contributors and integration bots—is sufficient for exploitation.

From Sandbox to RCE: The Three-Stage Injection Chain

Wiz Research demonstrated a successful exploit through a three-phase injection chain. The first injection sets rails_env=nonprod, moving hook execution from a sandboxed environment to an unprotected one. The second injection overwrites custom_hooks_dir with an attacker-controlled path, dictating where the server looks for scripts. Finally, the third injection defines repo_pre_receive_hooks, triggering malicious code execution before the push is even accepted.

By achieving unsandboxed execution as the git user, an attacker gains comprehensive control over the instance: file system read/write access, exposure of internal service configurations, and visibility into node-level secrets. On GitHub.com, affected storage nodes are shared across multiple tenants. Wiz confirmed that millions of repositories belonging to other users resided on the same physical servers, opening the door to massive, silent cross-contamination.

AI in the Black Box: How Wiz Decoded GitHub's Binaries

The breakthrough lies not just in the flaw’s severity, but in the discovery methodology. Wiz Research utilized AI-assisted reverse engineering tools, specifically IDA MCP, to rapidly analyze GitHub's closed-source binaries. This approach drastically reduced the time and resources required to map an opaque internal protocol, demonstrating that AI can effectively scale the auditing of cloud platforms previously considered inaccessible to systematic external inspection.

A methodological question remains: it is unclear whether the AI identified the attack surface autonomously or simply accelerated analysis following initial researcher direction. Regardless, this marks a shift in the security landscape: defenses based on code opacity lose efficacy when neural decompilers and language models can reconstruct semantics and data flow directly from bytecode.

Shared Storage Risks: Multi-tenant Exposure

The research confirms that the vulnerability on GitHub.com was not confined to the attacker’s target repository. Affected storage nodes hosted millions of third-party repositories, both public and private, sharing the infrastructure-level filesystem and processes. An RCE on a multi-tenant node would allow an attacker to inspect, copy, or alter code and secrets belonging to organizations with no prior relationship or trust connection to the malicious user.

GitHub mitigated the threat in its cloud environment within approximately six hours of the report, with a final fix applied on March 4, 2026. Despite this rapid response, the month-long gap between the cloud fix and public disclosure left many on-premise administrators unaware of the risk, as they often rely on public advisories to prioritize patching.

The risk profile differs sharply between SaaS and on-premise deployments. While GitHub can intervene centrally for cloud users, GHES administrators must act as the primary defenders, lacking the global visibility maintained by the cloud platform provider.

Response and Remediation Strategy

Given the critical nature and ease of exploitation, four immediate actions are recommended for organizations managing code on self-hosted infrastructure:

Immediately update GitHub Enterprise Server to the versions specified in the GitHub and CERT-AGID advisories, ensuring the build includes the fix for CVE-2026-3854.
Audit git push logs from recent months for anomalous push options containing parameters such as rails_env, custom_hooks_dir, or repo_pre_receive_hooks.
Review write access policies, tightening permissions for sensitive repositories and decommissioning legacy access for bots or external collaborators.
Inspect GHES instances for unauthorized hook files or filesystem modifications outside official deployment channels, as prior compromises could have established persistent backdoors.

The incident proves that cloud multi-tenancy, combined with insufficiently validated internal protocols, can turn a local flaw into a cross-tenant access mine. Furthermore, the use of AI for reverse engineering closed-source binaries shifts the balance between attackers and defenders, making opacity an increasingly fragile defense. For companies hosting code on GHES, the message is clear: the patch is available, but reaction time remains the defining risk factor.

FAQ

Was this vulnerability exploited in the wild?

There is currently no evidence of malicious exploitation. According to GitHub statements reported by The Hacker News, no active exploits have been detected in the wild.

Why were 90% of GHES instances still vulnerable at disclosure?

The fix applied on March 4, 2026, only covered GitHub’s managed cloud environment. On-premise installations require manual updates by administrators, who frequently wait for public advisories to schedule maintenance.

Did AI discover the flaw autonomously?

Wiz Research used AI-augmented tools like IDA MCP, but it has not been disclosed whether the AI operated autonomously or served to accelerate a manual investigation led by researchers.

Information verified via cited sources and accurate at the time of publication.