Dateline: April 29, 2026
How Wiz Turned a Git Push Into Full GitHub Server Compromise
GitHub just patched one of the most consequential vulnerabilities in its history. A single command, from any authenticated user, was enough to run arbitrary code on GitHub’s backend servers, potentially reaching millions of public and private repositories belonging to other users and organizations.
What Happened?
On March 4, 2026, researchers at Wiz discovered a critical injection flaw buried deep in GitHub’s internal git pipeline. The vulnerability, assigned CVE-2026-3854, affected both GitHub.com and GitHub Enterprise Server.
Here’s how it worked. When a user runs git push via SSH, the request passes through several internal services. One of those services, babeld, constructs an internal header called X-Stat, which carries security-critical configuration as semicolon-delimited key-value pairs. The problem: babeld copied git push option values directly into this header without sanitizing semicolons, the very character used as a field delimiter.
That meant a user could smuggle arbitrary fields into the header by crafting a push option with a semicolon in it. Since the header parser used last-write-wins logic, the injected fields silently overrode the legitimate ones.
From there, it escalated fast. The researchers chained three injections together: bypassing the sandbox, redirecting the hook script directory, and injecting a path traversal payload into a custom hook definition. The result was unsandboxed code execution as the git service user, with full filesystem access to the server.
GitHub mitigated the issue on GitHub.com within six hours of the report and released patches for all supported versions of GitHub Enterprise Server.
What made this discovery notable beyond the vulnerability itself: it is one of the first critical vulnerabilities in closed-source binaries found using AI, specifically AI-augmented reverse engineering tooling, which allowed the team to analyze compiled binaries and reconstruct internal protocols at a speed not previously feasible manually.
What’s the Impact?
On GitHub.com, the researchers confirmed code execution landed on shared storage nodes serving millions of repositories belonging to other users and organizations. The git service user, by design, has broad filesystem access across every repository on a given node. In other words, one compromised node meant every repo on it was within reach.
On GitHub Enterprise Server, the blast radius was even more direct: the same vulnerability granted full server compromise, including access to all hosted repositories and internal secrets.
The researchers confirmed the cross-tenant exposure using their own test accounts only, and did not access other organizations’ code. But the exposure was real. At the time of public disclosure, 88% of GitHub Enterprise Server instances had not yet applied the patch.
How to Avoid This
For GitHub.com users: No action needed. GitHub patched it server-side.
For GitHub Enterprise Server admins: Upgrade immediately to GHES version 3.19.3 or later. This is the version that patches CVE-2026-3854. If you are running any version at or below 3.19.1, your instance is still vulnerable. Wiz customers can use the pre-built Threat Center query to identify unpatched instances in their environments.
The broader lesson here cuts across any team running a multi-service architecture. When multiple services pass data through a shared internal protocol, each service’s assumptions about that data become an attack surface. In this case, one service trusted that push option values were safe to embed as-is. Another trusted every field in the header came from a legitimate source. The pre-receive hook assumed a specific environment variable could only hold one value in production. Each assumption was reasonable on its own. Together, they handed an attacker the keys.
Input sanitization at protocol boundaries isn’t optional. If user-controlled data flows into an internal header, a message bus, or any shared transport, validate and escape it before it gets there, not after.
