GitHub Enterprise Server Git Push Option Injection RCE (CVE-2026-3854)

Severity Assessment

• Exploitability: 8.5/10 — Requires push access to a repository; exploitation is a single crafted git push command using a standard git client; no additional tooling required
• Impact: 9.5/10 — RCE on GitHub.com shared storage nodes with cross-tenant repository exposure; full GHES server compromise including all hosted repositories and internal secrets
• Weaponization Risk: 7.5/10 — Technique is documented post-disclosure; requires authenticated repository access, limiting opportunistic exploitation but making it high-value for targeted attacks against GHES deployments
• Patch Urgency: 9.5/10 — GHES instances require upgrade; 88% of publicly reachable instances remained unpatched at time of public disclosure per Wiz telemetry
• Detection Coverage: 4/10 — Exploitation traffic is embedded in standard git push protocol; anomalous push option values are not logged or alerted by default in most git server deployments

Summary

CVE-2026-3854 is a command injection vulnerability in GitHub’s internal git push pipeline, discovered by Wiz Research and reported to GitHub on 2026-03-04. The flaw exists in how babeld — GitHub’s internal git proxy — passes user-supplied push option values into the X-Stat internal service header without sanitizing semicolons, which serve as the header’s field delimiter. Because the header format uses last-write-wins semantics for duplicate keys, an attacker can inject arbitrary metadata fields by embedding semicolons in push option values supplied via git push -o.

The vulnerability affected both GitHub.com and all supported GitHub Enterprise Server (GHES) versions up to 3.19.3. On GitHub.com, exploitation landed an attacker in a shared multi-tenant storage environment where the git service user had filesystem access to repository data belonging to millions of other users and organizations on the same node. On GHES, exploitation yielded full server compromise, including access to all hosted repositories and internal service secrets.

GitHub mitigated the vulnerability on GitHub.com within six hours of the initial report on 2026-03-04. GHES patches were released on 2026-03-10, with revised patch versions published on 2026-04-17. No exploitation in the wild was observed prior to public disclosure on 2026-04-28. This research was made possible in part by AI-augmented reverse engineering tooling (IDA MCP), which allowed Wiz to analyze GitHub’s compiled internal binaries at a speed not feasible with manual methods alone. GitHub awarded one of the highest rewards available in its Bug Bounty program for this finding.

CVSS 4.0: 8.7 HIGH (GitHub CNA) — CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N CVSS 3.1: 8.8 HIGH (NVD) — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H CWE: CWE-77 (Improper Neutralization of Special Elements used in a Command)

Exploit Chain

The vulnerability chains through three pipeline services — babeld, gitrpcd, and the compiled pre-receive hook binary — via a shared internal header (X-Stat) that uses semicolon-delimited key=value pairs with last-write-wins semantics. Wiz Research described the full technical chain in their public disclosure.

Stage 1: Push Option Injection

Git push options (supplied via git push -o) are copied by babeld directly into the X-Stat header as numbered fields without sanitizing semicolons. Since ; is the X-Stat field delimiter, a push option value containing a semicolon followed by a security-critical field name breaks out of its designated field and injects an additional, attacker-controlled key=value pair into the header. Because the injected pair appears later in the header than the legitimate pair, it wins under last-write-wins parsing and silently overrides the original value. Authentication is required (push access to any repository on the target), but no special privileges beyond standard contributor access are needed.

Stage 2: Sandbox Bypass via rails_env Override

The pre-receive hook binary has two execution paths controlled by the rails_env field in the X-Stat header: a production path that runs custom hooks inside a sandbox, and any other value that runs hooks directly with no isolation, as the git service user. By injecting a non-production rails_env value in Stage 1, an attacker switches the binary from the sandboxed production path to the fully unsandboxed direct execution path.

Stage 3: Arbitrary Binary Execution via Hook Path Traversal

Two additional injected fields complete the escalation to code execution. custom_hooks_dir sets the base directory the binary uses when resolving hook script paths; injecting an attacker-controlled value redirects all subsequent hook lookups. repo_pre_receive_hooks defines a JSON structure of hook scripts to run; injecting a crafted entry whose script field contains a path traversal sequence causes the binary to join the attacker-controlled base directory with the traversal payload and execute the resolved path directly — no sandbox, no arguments filter — as the git service user with full filesystem access.

Stage 4: GitHub.com Enterprise Mode Activation

On GitHub.com, a boolean flag in the X-Stat header controls whether the instance runs in enterprise mode; it defaults to false on GitHub.com, meaning the custom hooks code path is not reached under normal conditions. Wiz identified this flag through further binary reverse engineering and confirmed it was injectable via the same Stage 1 mechanism. Injecting the enterprise mode flag alongside the three fields above extended the full exploitation chain to GitHub.com shared infrastructure. Wiz confirmed the impact using their own test accounts and validated cross-tenant exposure without accessing any third-party repository contents.

Detection Guidance

Detection Method	Behavioral Indicator	Confidence
Git push log analysis	Push option values containing semicolons or patterns matching internal X-Stat field names (rails_env, custom_hooks_dir, repo_pre_receive_hooks)	High
GHES internal service logs	Non-production rails_env values in pre-receive hook execution traces; hook execution recorded outside the sandboxed path	High
Filesystem monitoring	New or modified files created by the git service user outside standard hook directories; execution of binaries resolved via path traversal	High
Process monitoring	Unexpected child processes spawned by the pre-receive hook binary that are not standard GHES hook scripts	High
Network monitoring	Outbound connections from the GHES git service user process to external infrastructure during push operations	Medium
GHES version check	Any instance below 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, or 3.19.4 is vulnerable — version detection is definitive	Definitive

GitHub.com users require no detection action; the vulnerability was mitigated on GitHub.com infrastructure within six hours of the initial report and no customer-side action is needed.

Indicators of Compromise

• Push option values containing semicolons followed by X-Stat field names (rails_env, custom_hooks_dir, repo_pre_receive_hooks, large_blob_rejection_enabled, reject_sha_like_refs, user_operator_mode) in git push server logs
• Non-production rails_env values recorded in GHES pre-receive hook execution traces, indicating the sandbox was bypassed
• Unexpected filesystem activity by the git service user, including directory traversal outside designated hook base directories
• Anomalous outbound network connections from GHES initiated by the git service process during or immediately following a push operation
• Modified or new executables in GHES hook directories or adjacent filesystem paths owned by the git service user

Recommended Mitigations:

1. Upgrade GHES immediately — Apply the latest patched release for your branch: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, or 3.19.4. At time of public disclosure, approximately 88% of reachable GHES instances remained on vulnerable versions.
2. GitHub.com users require no action — GitHub mitigated the vulnerability on GitHub.com infrastructure within six hours of the initial report; no customer-side remediation is needed.
3. Restrict push access temporarily — Until a patch is applied, consider limiting push access to trusted contributors on high-value repositories to reduce the attacker pool, noting that this does not eliminate the vulnerability surface.
4. Enable GHES audit log monitoring — Review audit logs for unusual push operations, unexpected pre-receive hook behavior, or git service user filesystem activity outside normal patterns.
5. Audit multi-service internal protocols — The vulnerability class — user input flowing unsanitized into internal protocol fields with last-write-wins semantics — applies broadly to multi-service architectures. Teams should audit how user-controlled data reaches shared internal headers or message formats.

Disclosure Timeline

• 2026-03-04 — Wiz Research Discovers and Reports Vulnerability

  Wiz Research discovers the X-Stat push option injection flaw using AI-augmented binary reverse engineering (IDA MCP) and confirms RCE on GHES 3.19.1. The vulnerability is reported to GitHub on the same day via the GitHub Bug Bounty program. GitHub acknowledges receipt and begins investigation.

• 2026-03-04 — GitHub Mitigates GitHub.com Within Six Hours

  GitHub deploys a fix on GitHub.com within six hours of the initial report, mitigating the vulnerability on the shared cloud infrastructure. No action is required for GitHub.com users.

• 2026-03-10 — CVE Assigned and GHES Patches Released

  CVE-2026-3854 is assigned with CVSS 4.0 score of 8.7 HIGH. GitHub releases patches for all supported GHES versions: 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, and 3.19.3.

• 2026-04-17 — GitHub Publishes Revised Patch Versions

  GitHub updates the NVD CVE entry with revised patch version references: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, and 3.19.4.

• 2026-04-28 — Public Disclosure

  Wiz Research publishes a detailed technical blog post. GitHub publishes a companion security blog. CISA-ADP adds the Wiz blog reference to the NVD record. At time of disclosure, Wiz data indicates approximately 88% of publicly reachable GHES instances remain unpatched.

Sources & References

• Wiz Research: Securing GitHub — RCE in GitHub.com and GitHub Enterprise Server (CVE-2026-3854) — Wiz Research, 2026-04-28
• National Vulnerability Database: CVE-2026-3854 Detail — National Vulnerability Database, 2026-03-10
• GitHub Security: Securing the Git Push Pipeline — Responding to a Critical RCE Vulnerability — GitHub Security, 2026-04-28
• GitHub: GitHub Enterprise Server 3.19.4 Release Notes — GitHub, 2026-04-17