GitHub CVE-2026-3854: One git push Was All It Took to Access Millions of Private Repositories

Wiz researchers discovered a critical RCE vulnerability in GitHub's git push pipeline — a single crafted push command gave attackers cross-tenant code execution on GitHub.com and full server compromise on GitHub Enterprise Server, with access to millions of private repositories belonging to other organizations.

SAN FRANCISCO — Wiz security researchers disclosed CVE-2026-3854 on April 28, revealing a critical remote code execution vulnerability in GitHub's git push pipeline that was silently patched on GitHub.com in March 2026. The flaw, carrying a CVSS score of 8.7, allowed an authenticated attacker with standard push access to execute arbitrary code on GitHub's backend infrastructure with a single crafted git push command — no malware, no phishing, no elevated token required. On GitHub.com, the blast radius was cross-tenant: Wiz researchers confirmed they reached shared storage nodes holding millions of public and private repositories belonging to other organizations. On GitHub Enterprise Server, the same attack chain delivered full server compromise including access to all hosted repositories and internal secrets.

Vulnerability Profile

How the Attack Worked

The vulnerability originated in GitHub's internal X-Stat protocol — a semicolon-delimited header passed between backend services during a git push operation. When a developer runs git push with custom push options (git push -o key=value), those values are embedded in the X-Stat header without sanitization. Because semicolons are used as delimiters in that header format, an attacker could inject additional metadata fields by including a semicolon in a crafted push option value. The injected fields overwrote trusted security configurations, allowing the attacker to pivot from the git proxy component (babeld) into unsandboxed code execution as the git service user. That service user has cross-tenant access — meaning a single developer account on any GitHub plan could reach repositories belonging to entirely different organizations on shared infrastructure. GitHub.com was patched 75 minutes after Wiz reported the issue on March 4. Public disclosure was held until April 28 to give GitHub Enterprise Server administrators time to patch. As of that disclosure date, 88% of GHES instances had not yet applied the fix.

The GHES Exposure Window and What to Check

GitHub Enterprise Server administrators who have not yet upgraded should treat this as an emergency patch. GitHub specifically recommends reviewing /var/log/github-audit.log for push operations containing semicolons in push options as an indicator of potential exploitation attempts during the exposure window. The fixed GHES versions are 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, and 3.20.0 — there is no workaround other than installing the patch. GitHub.com cloud users require no action. This is the same class of input validation failure that underpins many supply chain attacks — for context on how supply chain attacks work and spread. All vulnerability coverage is tracked on The CyberSignal.

What to do now

GitHub Enterprise Server administrators must upgrade to a fixed version immediately — 3.14.25 or later for your branch. There is no workaround. After patching, review audit logs for semicolons in push option values during the window between March 4 (when the flaw was reported) and your patch date. GitHub.com users require no action — the platform was patched within 75 minutes of the report. Organizations using GitHub Actions with self-hosted runners should audit runner configurations for any unauthorized additions during the exposure window. Review all secrets stored in GitHub Actions — tokens, API keys, and deployment credentials — for any organizations that operated GHES instances during the unpatched window.

The CyberSignal Analysis

Signal 01 — A Single git push as a Server Takeover Primitive

CVE-2026-3854 is not a bug in git itself — it is a trust boundary mistake in GitHub's multi-service architecture. Git legitimately allows push options. GitHub's internal proxy legitimately embeds those options in metadata headers. The mistake was assuming that characters permitted by git would be safe to embed in an internal protocol that used those same characters as delimiters. This is a well-documented class of injection vulnerability applied to an exceptionally high-value attack surface: the server-side pipeline that processes every git push on one of the world's largest code hosting platforms.

Signal 02 — Cross-Tenant RCE Is the Most Dangerous Cloud Primitive

The cross-tenant blast radius is what elevates this vulnerability beyond a typical RCE. An attacker who achieves RCE on GitHub's shared infrastructure is not compromised to their own repositories — they have access to millions of other organizations' private code, secrets, and deployment configurations. The economic and espionage value of that access is enormous. The fact that Wiz confirmed this blast radius in a responsible disclosure context — and that GitHub patched it in 75 minutes — reflects a mature bug bounty response. But the 88% of GHES instances still unpatched at public disclosure represents a substantial ongoing risk.

Signal 03 — The 88% Unpatched GHES Rate Is a Structural Enterprise Security Problem

GitHub Enterprise Server is used by organizations that chose self-hosted deployment specifically for security and compliance control. The same organizations are 88% unpatched on a critical RCE two months after the cloud version was fixed and nearly a month after patches were available. This is not a GitHub problem — it is an enterprise patch management problem applied to developer infrastructure. Security teams that have strong patch processes for servers and endpoints but weak processes for developer tooling are systematically exposed at the most credential-dense layer of their environment.

Sources