GitHub Enterprise RCE: A Single 'git push' Puts Corporate Backends at Risk

CVE-2026-3854 allows Remote Code Execution on GitHub Enterprise Server via user-controlled push options. Reports indicate that 88% of self-hosted instances rem…

On April 28, 2026, details emerged regarding a critical vulnerability in GitHub Enterprise Server, tracked as CVE-2026-3854, which enables remote code execution (RCE) through a standard git push operation. Researchers at Wiz demonstrated that user-controlled push option values are not properly sanitized before being inserted into multi-service internal headers. This flaw allows for the injection of additional metadata that can manipulate hook execution and bypass security sandboxes. With nearly 90% of self-hosted instances still exposed, the risk to enterprise environments is immediate, necessitating urgent patching.

Key Takeaways

CVE-2026-3854 grants RCE on GitHub Enterprise Server to any user with basic push access to a repository.
The exploit leverages unsanitized git push options within internal headers that use delimiters interpretable as field separators.
Attackers can manipulate metadata such as rails_env and hook directories to execute arbitrary code as the 'git' user, bypassing sandboxes.
GitHub has issued patches for versions 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, and 3.19.3, yet nearly 90% of self-hosted instances remain vulnerable.

Anatomy of the Internal Protocol Injection

During a git push, clients can include key-value pairs known as push options to control server-side behaviors, such as triggering CI pipelines or managing merges. In GitHub Enterprise Server, these values transit through an ecosystem of internal microservices that exchange metadata via dedicated headers.

The format of these headers utilizes a delimiter that is not treated as a reserved character. If user input contains this specific character, downstream parsers interpret it as a separator for a new field. Consequently, an attacker can inject unauthorized key-value pairs, altering the behavior of subsequent services. The root cause lies not in the open-source Git codebase, but in a proprietary closed-source protocol used for backend orchestration, where an implicit assumption of trust between services led to an improper neutralization of special elements.

From Push Options to Backend Compromise: The Attack Chain

By injecting additional metadata through the vulnerable delimiter, the attack chain described by researchers allows for the diversion of server-side hooks—the processes GitHub uses to handle repository events. By manipulating the rails_env value, an attacker can force an insecure execution mode, disabling protections that typically restrict the operational context of scripts.

Combining this with hook directory redirection and path traversal techniques, an attacker can execute arbitrary files with the privileges of the 'git' user. From this vantage point, the compromise can escalate vertically to the entire host system, jeopardizing all repositories and internal data stored on the machine. There are currently no known public indicators of compromise (IoC) to detect past exploitation, complicating retroactive security audits for incident response teams.

Rapid Response, Sluggish Adoption

The original Wiz report is dated March 4, 2026. According to the timeline reported by SecurityAffairs, GitHub released patches within approximately two hours of receiving the disclosure, providing fixes for versions 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, and 3.19.3. Despite the vendor's speed, nearly 90% of self-hosted instances were still found to be vulnerable at the time of the research publication on April 28, 2026.

While the investigation found no evidence of exploitation outside of controlled environments or documented compromises of customer data, the massive exposure highlights a significant governance challenge in on-premises and self-managed infrastructures. In these environments, maintenance windows are often delayed by weeks or months, leaving the perimeter open to anyone with write access.

"GitHub Enterprise Server customers should upgrade immediately – at the time of this writing, our data indicates that 88% of instances are still vulnerable." — Wiz, quoted by SecurityAffairs

The Systemic Risk of Custom Microservice Delimiters

This incident underscores a dangerous architectural pattern: heterogeneous services exchanging metadata through delimited formats without rigorous sanitization or intermediate validation layers. When each microservice assumes its predecessor has already validated the data, the chain of trust becomes a single point of failure.

In this instance, a simple git push was sufficient to compromise the backend infrastructure of a platform used by millions. The lesson extends beyond GitHub: any organization utilizing custom internal protocols—undocumented APIs, proprietary headers, or legacy binary formats—must treat every byte from the end-user as untrusted by default, regardless of how many internal hops that data has traversed.

Remediation and Mitigation

Update immediately self-hosted instances to one of the patched versions released by GitHub: 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, or 3.19.3. If downtime cannot be scheduled immediately, administrators should at least force a reboot of application services post-update to ensure the fix is active.
Review logs of recent push operations for anomalous push options or suspicious patterns that might indicate injection attempts, despite the lack of public IoCs for automated comparison.
Restrict push permissions to essential accounts only until the update is finalized, thereby reducing the internal attack surface and limiting the number of users capable of triggering the exploit chain.
Implement network isolation for unpatched instances where possible, limiting remote access from non-corporate networks until the fix is applied and verified.

The discovery by Wiz is not an isolated bug, but a symptom of a widespread fragility: when internal protocols treat user data as trusted, the boundaries between microservices can collapse with a single character.

For organizations hosting code on GitHub Enterprise Server, the priority is no longer if they should update, but how quickly they can. Zero-trust architecture cannot stop at the network perimeter if internal metadata travels without validation.

Frequently Asked Questions

Does this vulnerability affect GitHub.com (Cloud) users?

There is no confirmation that this attack chain is exploitable on the multi-tenant production infrastructure of GitHub.com. Available sources suggest a theoretical potential on shared storage nodes within the cloud environment, but the security alerts and patches are specifically targeted at self-hosted GitHub Enterprise Server instances.

SaaS users do not have autonomous mitigation actions to take and must rely on vendor updates, as the cloud architecture is not managed locally.

How can a simple 'git push' lead to Remote Code Execution?

The vulnerability exists because user-provided push option values are embedded into internal headers without neutralizing dangerous delimiters. This allows an attacker to break the message structure and inject malicious metadata, such as execution modes or hook paths, eventually gaining control over backend processes.

The issue is not with the standard Git protocol, but with how GitHub Enterprise Server integrates it with internal microservices under the assumption that internal data is pre-sanitized.

What are the risks of remaining unpatched?

An attacker with write access to a single repository can execute arbitrary code on the Enterprise Server. This leads to full system compromise, access to all repositories on the instance, and the potential exfiltration of sensitive internal data.

The threat is tangible: with nearly 90% of instances still vulnerable and no public IoCs available, it is difficult to rule out unauthorized access prior to patching. Administrators should treat this update as an incident prevention measure rather than routine maintenance.

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