GitHub Discloses Critical Git Push RCE That Could Have Exposed Millions of Private Repositories, With 88 Percent of Self-Hosted Servers Still Unpatched

Overview

GitHub on April 28 disclosed a critical remote code execution vulnerability in the git push pipeline that, before being patched, allowed any authenticated user with push rights to execute arbitrary commands on the company’s backend infrastructure. The flaw, tracked as CVE-2026-3854, was reported by researchers at cloud security firm Wiz on March 4 and patched on github.com within roughly two hours, as described in GitHub’s own post-mortem. The disclosure on April 28 revealed that, despite patches being available for weeks, around 88% of internet-reachable GitHub Enterprise Server (GHES) instances were still vulnerable at the time the bug went public.

What We Know

• The vulnerability sits inside GitHub’s internal git proxying and RPC layer. According to GitHub’s security team, “user-supplied push option values, such as those provided through git push -o, were not properly sanitized before being included in internal service headers” used to communicate between front-end and back-end services. Because the internal metadata format used a delimiter character that could also appear in user input, an attacker could inject additional fields and influence how push hooks were executed on the server.
• The exploitation primitive came down to a single command. As The Hacker News reported, the bug was rated CVSS 8.7 and could be triggered with a maliciously crafted git push, requiring only push access to a repository on the target instance. CVE-2026-3854 affects github.com, GitHub Enterprise Cloud (including the Data Residency and Enterprise Managed Users variants), and GitHub Enterprise Server.
• GitHub’s response was unusually fast for a flaw of this scope. GitHub said it reproduced the issue within 40 minutes of receiving Wiz’s report and deployed a fix to github.com less than two hours later, on March 4 at 19:00 UTC. The company then prepared and shipped patched releases for every supported GHES branch — versions 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, and 3.20.0 — before going public.
• The blast radius on the cloud side was the most alarming part of the finding. According to Sagi Tzadik of Wiz, quoted by BleepingComputer, “on GitHub.com, this vulnerability allowed remote code execution on shared storage nodes,” with the same nodes hosting repositories belonging to many tenants. Wiz characterized the issue as one that could have exposed “the codebases of nearly all of the world’s biggest enterprises, making this one of the most severe SaaS vulnerabilities ever found.”
• GitHub said no customer data was taken before the patch. GitHub Chief Information Security Officer Alexis Wales stated that the only logs corresponding to the vulnerable code path “mapped to the Wiz researchers’ own testing activity. No other users or accounts triggered this code path,” and that no customer data was accessed, modified, or exfiltrated as a result of the bug on the cloud platform.
• The picture for self-hosted GitHub is much worse. BleepingComputer reported that, at the time of public disclosure on April 28, roughly 88% of reachable GHES instances on the internet were still running unpatched versions, leaving organizations that self-host their git infrastructure exposed to a flaw whose exploitation requires only a single git push by an authenticated developer or contractor.

How the Exploit Works

At a technical level, the attack chained together three components in GitHub’s git push pipeline. According to The Hacker News, GitHub uses an internal proxy called babeld that forwards git operations to an RPC server, and the proxy copied push option values into a custom X-Stat header used to carry per-request metadata such as the Rails environment and pre-receive hook configuration.

Because X-Stat uses a delimiter that can also appear in user-supplied data, and because the downstream parser used last-write-wins semantics, an attacker who controlled push option values could inject extra fields. By smuggling fields such as rails_env, custom_hooks_dir, and repo_pre_receive_hooks, the attacker could redirect hook execution and bypass the sandbox that normally constrains pre-receive scripts. The end result, as GitHub described it, was that crafted push options “could override the processing environment used for executing repository hooks, allowing an attacker to bypass sandboxing protections” and run arbitrary commands as the git service account.

On github.com, that account had visibility into shared storage holding repositories from many tenants — the basis for Wiz’s claim of cross-tenant repository access. On GitHub Enterprise Server, the same technique gave full access to whatever repositories and secrets the targeted instance hosted.

What We Don’t Know

• Whether anyone besides Wiz found CVE-2026-3854 before March 4. GitHub said its log review on github.com turned up no other triggers of the vulnerable code path, but BleepingComputer noted that GHES customers will need to inspect their own audit logs because the company can only speak to its hosted service.
• The precise count of unpatched GHES instances behind firewalls. The 88% figure cited at disclosure is based on internet-reachable servers, which is only a subset of all enterprise deployments; private GHES instances inside corporate networks could be patched faster, slower, or not at all, and there is no public dataset that captures this.
• How quickly GHES operators will move to apply the fix. GitHub has shipped patches across every supported release line, but enterprise upgrade cycles typically lag cloud patching, and a vulnerability that requires only push-level credentials provides a wide pool of potential attackers, including third-party contractors and any compromised developer account.

Why It Matters

Git and GitHub have become the de facto control plane for most of the world’s open source and proprietary software, which makes the integrity of the git push pipeline a piece of supply-chain plumbing that the entire industry depends on. CVE-2026-3854 is not a flaw in git itself — it lives in GitHub’s internal protocol layer — but the fact that a single, standard-looking push command could pivot into RCE on shared infrastructure underscores how thin the boundary is between developer workflows and the systems that store private code and secrets.

The split between GitHub’s two-hour cloud patch and the months-long lag for self-hosted servers also illustrates a recurring pattern in modern open source infrastructure: managed services receive critical security work invisibly and quickly, while self-hosted deployments remain on owner-operator timelines. With 88% of reachable GHES instances unpatched at disclosure, the immediate security work for thousands of organizations is now to upgrade to one of the patched releases, audit /var/log/github-audit.log for push operations containing semicolons in push options, as GitHub recommends, and to assume that any push-capable account on a vulnerable instance could have been used to run code on the server.