A critical RCE in the git push path

On March 4, 2026, GitHub received a vulnerability report through its Bug Bounty program from researchers at Wiz. The finding described a critical remote code execution vulnerability affecting github.com and all GitHub Enterprise offerings. Within 40 minutes of receipt, the security team reproduced the issue and confirmed its severity; by 7:00 p.m. UTC that same day, a fix had been deployed to github.com. The subsequent forensic investigation determined that there was no exploitation of the vulnerability outside of the researchers' own testing.

How a crafted push option became a server-side exploit

The vulnerability centered on how user-supplied git push options are processed during a push operation. These are a legitimate git feature that lets clients send key-value strings to the server. Push operations pass through several internal services, and metadata about the push—including the repository type and target environment—is exchanged using an internal protocol.

The attack required only a single git push command with a carefully crafted push option. Because user-supplied values were incorporated into the internal metadata without sufficient sanitization, an attacker could inject additional fields that downstream services would interpret as trusted internal values. This was possible because the delimiter character used in the metadata format could also legitimately appear in user input.

By chaining several injected values, the researchers demonstrated that an attacker could:

  • Override the environment in which the push was processed.
  • Bypass the sandboxing protections that normally constrain hook execution.
  • Execute arbitrary commands on the GitHub server handling the push.

Anyone with push access to a repository—even a repository they created themselves—could trigger the flaw.

Patch and remediation

The fix deployed to github.com ensures that user-supplied push option values are properly sanitized and can no longer influence internal metadata fields. For GitHub Enterprise Server, patches were prepared across all supported releases: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0, or later. The vulnerability is tracked as CVE-2026-3854.

GitHub Enterprise Cloud, including the Managed Users and Data Residency configurations, was patched on March 4, 2026; no action is required from customers of those services. GitHub strongly recommends that GHES customers upgrade to the latest patch release as soon as possible.

Verifying no exploitation occurred

A key property of the vulnerability aided the forensic investigation: exploitation forces the server to take a code path that is never exercised during normal operations on github.com. This is an inherent consequence of the injection mechanism, meaning an attacker could not trigger the flaw without also leaving this distinctive trace.

GitHub logged this anomalous code path and queried telemetry for any instance of it being executed. The results showed:

  • Every occurrence mapped to the Wiz researchers' own testing activity.
  • No other users or accounts triggered the code path.
  • No customer data was accessed, modified, or exfiltrated.

For GHES instances, exploitation would require an authenticated user with push access. GitHub recommends reviewing /var/log/github-audit.log for push operations containing ; in push options as an added precaution.

Root cause beyond input sanitization

The investigation surfaced a defense-in-depth issue that compounded the input sanitization flaw. The exploit worked in part because the server environment contained a code path that was never intended to be used in that configuration—it existed on disk as part of the container image, but was only meant for different product deployments. Prior deployment methods had excluded this code, but that exclusion was not preserved when the deployment model changed.

GitHub has removed the unnecessary code path from environments where it should not exist. The input sanitization fix is the primary remediation; this additional hardening limits what an attacker could accomplish if a similar injection vulnerability were discovered in the future.

The vulnerability was discovered and disclosed by researchers at Wiz. GitHub notes that the finding will receive one of the highest rewards in the history of its Bug Bounty program.