CVE-2026-3854: Critical RCE Vulnerability in GitHub Triggered via Single ‘git push’

A specifically crafted git push command can execute remote code on GitHub.com and GitHub Enterprise Server. While the cloud environment was patched in March, n…

On April 28, 2026, Wiz Research published technical details for CVE-2026-3854, a critical remote code execution (RCE) vulnerability affecting GitHub.com and GitHub Enterprise Server (GHES). The flaw is triggered by a single git push command containing malicious push options. It exploits a failure to sanitize the ; delimiter within the internal X-Stat header, allowing an attacker to overwrite security parameters and compromise the entire instance, including shared cloud storage nodes. Although GitHub patched its cloud systems on March 4, 2026—within six hours of the initial report—nearly 88% of on-premise instances were still vulnerable at the time of disclosure, necessitating urgent administrative action.

Key Takeaways

A single git push command with crafted options allows for field injection in the internal X-Stat header via the ; delimiter, leveraging the last-write-wins semantics of downstream parsers.
On GitHub.com, the exploit chain enabled RCE on shared storage nodes, posing a cross-tenant risk. On GitHub Enterprise Server, it allows for a complete sandbox bypass and full server takeover.
The cloud fix was deployed on March 4, 2026, less than six hours after reporting. Technical details were withheld until April 28, 2026, to provide on-premise users time to update.
As of the disclosure date, nearly 88% of GitHub Enterprise Server instances remained unpatched. GitHub states it has found no evidence of malicious exploitation outside of Wiz Research’s controlled testing.

How a Crafted Git Push Overwrites Security Parameters

The core of the vulnerability lies in a parsing discrepancy between GitHub’s git front-end and its internal services. When an authenticated user sends a push with specific options, the babeld component inserts push_option_x values into the internal X-Stat header without stripping the ; character used as a separator. By injecting a semicolon into the option value, an attacker can generate additional fields that downstream services interpret as legitimate parameters.

Downstream, the gitrpcd service and pre-receive hook parsers apply a last-write-wins logic: the last field with a given name overwrites any previous instances. By injecting rails_env, custom_hooks_dir, and repo_pre_receive_hooks, an attacker can replace the intended security configuration with arbitrary values, transitioning from a sandboxed environment to direct code execution as the git service user.

Wiz discovered the flaw by analyzing GitHub’s closed-source git pipeline binaries using AI-assisted reverse engineering tools, specifically IDA MCP. This approach allowed researchers to map metadata flow across services written in different languages, identifying the exact discrepancy in how the internal delimiter was handled.

From Sandbox Bypass to Full Platform Compromise

On on-premise GHES instances, the pre-receive hook manages two execution paths based on the rails_env value. Under normal conditions, the production value triggers a sandbox that restricts commands. By overwriting this with any other value, the system executes code directly as the git user, bypassing all security constraints. From this point, an attacker can upload arbitrary hooks and gain total control of the server.

Unsandboxed execution as the git user grants full filesystem access (read and write) and visibility into internal service configurations. Wiz security researcher Sagi Tzadik described the scenario as a total "pwnage" of the GHES instance, enabling lateral movement and platform-level persistence.

On the GitHub.com cloud platform, the same chain allowed code execution on storage nodes shared across multiple tenants. According to Wiz, this exposed over a million public and private repositories to cross-tenant access risks, though GitHub maintained that no unauthorized exploitation was detected beyond the researchers' activities.

"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 (via The Hacker News)

The Response Timeline: From Silent Patch to Disclosure

Following the report from Wiz, GitHub reproduced the bug in approximately 40 minutes, identifying the root cause by 17:45 UTC on March 4, 2026. Rapid coordination allowed the team to isolate the issue before technical details reached the public, significantly limiting the cloud exposure window.

The mitigation for GitHub.com was deployed within hours of the report; while The Hacker News cites a two-hour window, Wiz indicates a maximum of six hours. Regardless of the minor discrepancy, the response was exceptionally swift given the criticality of the flaw.

GitHub then observed a nearly seven-week buffer to allow GitHub Enterprise Server administrators to apply patches before full disclosure. Technical details were released on April 28, 2026, with the Italian government's CERT-AGID issuing a formal advisory shortly after the researchers' publication.

Mitigation and Security Recommendations

Administrators of GitHub Enterprise Server must update immediately to the following patched versions: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7 or 3.18.8, 3.19.4, 3.20.0, or later. Unpatched instances remain exposed to the RCE chain, which results in total server compromise.

Security teams should examine git push audit logs from recent months for anomalous options containing the ; character or unexpected values for rails_env and custom_hooks_dir. Because the exploit requires push permissions and authentication, monitoring should focus on internal users or compromised accounts with write access to repositories.

Following the patch, it is recommended to verify that no unauthorized pre-receive hooks or persistent changes exist in the custom_hooks_dir. An attacker could have leveraged the pre-disclosure window to install silent backdoors. Furthermore, organizations should monitor processes executed by the git service user for abnormal variations in the rails_env environment or execution outside the expected sandbox, particularly for GHES instances where immediate patching is delayed by change management constraints.

When Internal Service Trust Becomes a Threat Vector

The CVE-2026-3854 case demonstrates that authenticated input is not inherently safe when it crosses trust boundaries between services using different parsers. A standard git feature—push options—was transformed into an RCE vector because internal systems failed to anticipate that a protocol delimiter could be re-injected by the payload itself.

The architectural paradox is that while GitHub's pipeline did not trust the external user, it implicitly trusted its own internal X-Stat metadata. While AI-assisted reverse engineering accelerated the discovery, the fundamental lesson remains human: internal protocol delimiters must be treated with the same skepticism as raw internet input.

This vulnerability did not stem from a cryptographic failure or an authentication error, but from overlooked parsing hygiene between components presumed to be reliable. For organizations running GHES on-premise, the priority is now verifying that the gap between the cloud fix and the public disclosure was not exploited to establish persistence.

Frequently Asked Questions

Does the attack require a modified git client or special privileges?
No. The exploit works with a standard git client. The only requirement is an authenticated user with push permissions to a target repository. Administrative privileges are not required.

Do GitHub.com (Cloud) users need to take action?
No. The fix was applied server-side on March 4, 2026. Cloud users do not need to install patches or change configurations; the current risk is limited to unpatched on-premise installations.

Why were technical details released weeks after the cloud fix?
GitHub waited approximately seven weeks to allow GitHub Enterprise Server administrators sufficient time to install updates before the exploit method became public and easily replicable by threat actors.

Information has been verified against cited sources and is current as of the date of publication.