In modern software development, git push is as common as a heartbeat. But what happens when that heartbeat carries a lethal payload? On March 4, 2026, researchers at Wiz uncovered a critical Remote Code Execution (RCE) vulnerability, tracked as CVE-2026-3854, that struck at the core of GitHub’s internal infrastructure.
This flaw allowed any authenticated user to achieve full server compromise on GitHub Enterprise Server (GHES) and cross-tenant data access on GitHub.com. Remarkably, the attack required no zero-day dependencies or complex tools—just a standard git client and a single command. +1
This post deconstructs the injection mechanics, the RCE chain, and the groundbreaking AI-assisted research that brought this “invisible” threat to light.
The Root Cause: Protocol Confusion in Babeld
The vulnerability stems from CWE-77 (Improper Neutralization of Special Elements) within GitHub’s internal git proxy, known as babeld.
When you run a command like git push -o "option", the “push option” is passed to the server. GitHub’s babeld proxy takes these user-supplied strings and packs them into an internal header called X-Stat.
The Injection Vector
The X-Stat header uses semicolons as delimiters (e.g., field1=val1;field2=val2). However, babeld failed to sanitize semicolons within the push option itself. By including a semicolon in the push option, an attacker could effectively “break out” of the intended field and inject entirely new key-value pairs into the protocol.
Because the downstream service (gitrpcd) uses last-write-wins semantics, the injected fields at the end of the header would override the legitimate security configurations set at the beginning.
The RCE Chain: Bypassing the Sandbox
Achieving code execution required chaining three specific injected fields to subvert GitHub’s “pre-receive hook” logic. Pre-receive hooks are scripts that run before a push is accepted—normally, these are heavily sandboxed. +1
Step 1: Environment Hijacking
By injecting rails_env=development;, the attacker tricked the server into switching from the “production” execution path (which is sandboxed) to a “development” or “non-production” path. In this mode, GitHub’s internal binaries execute hooks directly on the host for debugging purposes.
Step 2: Directory Redirection
The attacker then injected custom_hooks_dir=/tmp;. This told the server to look for hook scripts in a directory the attacker could potentially control, rather than the secure, read-only hooks directory.
Step 3: Path Traversal to Execution
Finally, by injecting a crafted repo_pre_receive_hooks entry containing a path traversal payload (e.g., ../../../../bin/sh), the attacker forced the unsandboxed binary to execute an arbitrary system binary as the git service user.
Impact: On GitHub Enterprise Server, this resulted in a full “root-level” equivalent compromise of the instance. On GitHub.com, it allowed access to the filesystem of shared storage nodes housing millions of private repositories.
AI-Augmented Research: A New Frontier
Perhaps the most significant aspect of CVE-2026-3854 is how it was found. GitHub’s internal proxies are closed-source, compiled binaries. Historically, reverse-engineering these would take months of manual effort.
Wiz researchers leveraged AI-augmented reverse engineering (using tools like IDA MCP) to reconstruct GitHub’s internal protocols at scale. This allowed them to map how data flowed through the opaque babeld and gitrpcd services in a fraction of the time, signaling a major shift in how vulnerability research will be conducted in the age of AI.
Remediation and Patching Requirements
GitHub patched the cloud version (GitHub.com) within six hours of the report. However, GitHub Enterprise Server (GHES) administrators must manually apply updates. As of late April 2026, data suggests nearly 88% of instances remain unpatched.
Fixed Versions Table
| GHES Series | Minimum Fixed Version |
|---|---|
| 3.19 | 3.19.4+ |
| 3.18 | 3.18.8+ |
| 3.17 | 3.17.13+ |
| 3.16 | 3.16.16+ |
| 3.15 | 3.15.20+ |
| 3.14 | 3.14.25+ |
Export to Sheets
FAQs Section
Q1: Do I need to be an admin to exploit this? A: No. Any user with “push” access to a single repository—even a low-level developer—could trigger the RCE chain.
Q2: Was any data stolen from GitHub.com? A: GitHub’s forensic investigation confirmed that no exploitation occurred prior to the Wiz disclosure. The researchers only accessed their own test accounts to validate the vulnerability.
Q3: How do I check my logs for attack attempts? A: Audit /var/log/github-audit.log on your GHES instance. Look for git.push events where the push_options field contains semicolons (;) followed by keywords like rails_env or custom_hooks_dir.
Q4: Is this a vulnerability in Git itself? A: No. This is a vulnerability in GitHub’s implementation of how it proxies and processes Git protocol options internally.
Conclusion: Audit Your Internal Protocols
CVE-2026-3854 is a stark reminder that the “connective tissue” between microservices is often the weakest link. When data travels from a proxy (Go/C++) to a backend service (Ruby/Rails), the assumptions made about sanitization can fall through the cracks
