One Git Push Gave Attackers RCE Access to Millions of GitHub Repositories

Cybersecurity researchers have disclosed a critical security vulnerability impacting GitHub.com and GitHub Enterprise Server that could allow an authenticated user to obtain remote code execution with a single "git push" command. The flaw, tracked as CVE-2026-3854, is one of the most severe platform-level vulnerabilities GitHub has ever faced. Not a misconfigured workflow, not a leaked token. A bug buried inside the infrastructure that processes every single push operation on the planet's largest code host.

The vulnerability was discovered by Wiz researchers through AI-augmented reverse engineering of closed-source compiled binaries, which is itself a notable shift in how security research gets done. The researchers didn't have source code to work from. They used AI tooling to analyze compiled binaries and still found a flaw that GitHub's own engineers missed.

GitHub is home to hundreds of millions of repositories spanning open source projects, enterprise codebases, and critical infrastructure, and its internal git infrastructure — the pipeline that processes every git push — is one of the most security-sensitive systems on the internet. That context makes this finding land harder than a typical CVE disclosure.

What Is CVE-2026-3854

The flaw is a case of command injection that could allow an attacker with push access to a repository to achieve remote code execution on the instance. Push access is not a high bar. Any user can create their own repository and immediately have push access to it.

The flaw stems from an injection vulnerability in GitHub's internal X-Stat header, a semicolon-delimited protocol that passes security metadata between the platform's internal services. When a user runs git push -o, GitHub's babeld proxy embeds those user-supplied strings directly into the X-Stat header without stripping semicolons.

According to GitHub's own advisory: "During a git push operation, user-supplied push option values were not properly sanitized before being included in internal service headers. Because the internal header format used a delimiter character that could also appear in user input, an attacker could inject additional metadata fields through crafted push option values."

How the Exploit Chain Works

The attack doesn't stop at header injection. The remote code execution chain strings together three injections: inject a non-production rails_env value to bypass the sandbox, inject custom_hooks_dir to redirect the hook directory, and inject repo_pre_receive_hooks with a crafted hook entry that triggers path traversal to execute arbitrary commands as the git user.

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, according to GitHub CISO Alexis Wales.

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. One service assumed push option values were safe to embed verbatim. Another assumed every field in the X-Stat header was set by a trusted source. The pre-receive hook assumed an environment variable could only be production in production. Each assumption was reasonable in isolation — and dangerous in combination.

The Cross-Tenant Exposure Problem

The RCE itself is bad enough. What makes CVE-2026-3854 especially severe is what happens after you land on the server.

GitHub.com is a multi-tenant platform. Repositories belonging to millions of different organizations and users are stored on shared backend infrastructure. When Wiz achieved code execution on GitHub.com, they landed on a shared storage node running as the git user. That user exists to serve all repository operations across the node. By design, it has broad filesystem access to every repository hosted on that node — meaning compromising this user gave read access to any repository on the node, regardless of which organization or user owned it.

Wiz enumerated repository index entries accessible from two compromised nodes and found millions of entries across each. To be clear, they did not access the contents of other tenants' repositories. They validated the cross-tenant exposure using only their own test accounts, confirming that the git user's filesystem permissions would allow reading any repository on the node.

Key Technical Highlights

• CVE-2026-3854 carries a CVSS score of 8.7 and is classified as a command injection vulnerability.
• Wiz noted that the issue is "remarkably easy" to exploit and allows remote code execution on shared storage nodes.
• The vulnerability affects GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, GitHub Enterprise Cloud with Enterprise Managed Users, and GitHub Enterprise Server.
• On Enterprise Server, it could lead to full system compromise, including access to all repositories and sensitive internal data.
• The discovery was made using AI-augmented reverse engineering of closed-source compiled binaries, a technique that is becoming increasingly common in offensive security research.

GitHub's Response and the Patch Timeline

On March 4, 2026, GitHub received the vulnerability report through its Bug Bounty program. In less than two hours, the team had validated the finding, deployed a fix to GitHub.com, and begun a forensic investigation that concluded there was no exploitation.

GitHub's forensic investigation confirmed no exploitation occurred prior to disclosure. That's the best-case outcome for a bug of this severity.

GitHub stated this finding will receive one of the highest rewards in the history of their Bug Bounty program, which has been a cornerstone of their security program for over a decade.

For Enterprise Server, the situation is more urgent. GitHub Enterprise Server customers should upgrade immediately. At the time of writing, Wiz's data indicates that 88% of instances are still vulnerable. The patch is available in GHES version 3.19.3 or later.

GHES administrators should also audit /var/log/github-audit.log for push operations containing unusual special characters in push option values as indicators of prior exploitation attempts.

What This Means for the Industry

This vulnerability doesn't exist in isolation. Some of the most significant software supply chain incidents over the past year were carried out by threat actors who exploited vulnerabilities in GitHub, including major attacks such as Ultralytics, Singularity, and the GitHub Action tj-actions/changed-files compromise. CVE-2026-3854 sits at a different level — it's not a misconfigured workflow or a compromised token. It's a flaw in the platform's core push infrastructure.

The vulnerability chain highlights a pattern that extends well beyond GitHub. 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. Any platform with a polyglot internal service architecture should treat this disclosure as a prompt to audit their own delimiter-handling and input sanitization across service boundaries.

Final Thoughts

What stands out to me about this research isn't just the severity of the bug — it's the method used to find it. Wiz used AI to reverse-engineer closed-source binaries and surface a flaw that had been sitting in production infrastructure. That's a meaningful signal about where vulnerability research is heading. The attack surface hasn't changed, but the tools available to find bugs in it have gotten dramatically more capable.

The three-step injection chain is also worth studying carefully. None of the individual assumptions — that push options are safe to embed, that X-Stat fields come from trusted sources, that rails_env can only be production in production — were obviously wrong in isolation. The bug lives in the composition of those assumptions, not in any single one of them. That's the kind of vulnerability that survives code review and automated scanning alike.

GitHub's two-hour response from report to patch on GitHub.com is legitimately impressive for a platform at this scale. The 88% of unpatched Enterprise Server instances is the part I'd watch closely over the next few weeks. What do you think? Drop your thoughts in the comments.

---