GitHub Push-Pipeline RCE (CVE-2026-3854), Patched on github.com, GHES Admins Must Upgrade

Wiz Research and GitHub's security team today disclosed CVE-2026-3854, a high-severity remote code execution flaw with critical practical impact in GitHub's internal git push pipeline. A single git push command, with crafted -o push options, was enough for any authenticated user with push access to a repository on the affected instance to achieve arbitrary command execution on GitHub's backend. Wiz reported the bug March 4, 2026; GitHub deployed a same-day fix to github.com / GHEC and released GHES patches March 10. github.com, GitHub Enterprise Cloud, GHEC with Data Residency, and GHEC with Enterprise Managed Users are already patched and require no user action. GitHub Enterprise Server operators are the group that needs to act immediately. GitHub's forensic investigation found no evidence of pre-disclosure exploitation on github.com.

Version note: Some early advisory text and downstream mirrors still show superseded fixed versions. The table above follows GitHub's current remediation guidance and the current NVD / CVE record. A small number of earlier patch releases technically contained the CVE fix but were later superseded or unpublished for operational reasons (for example, GHES 3.18.6 included the fix and was later unpublished, with 3.18.7 as the valid current baseline). When in doubt, install the latest patch release for your supported GHES line, not merely the listed baseline. For 3.20.x: 3.20.0 and later include the fix; use the latest 3.20 patch release if already on that line.

Scope note: The formal CVE / NVD record is scoped to GitHub Enterprise Server. The github.com / GHEC discussion in this guide is included because Wiz demonstrated the same bug path on GitHub's hosted infrastructure before GitHub patched it on March 4.

What you actually need to do

If you run GitHub Enterprise Server

1. Identify your current GHES version. From the Site Admin dashboard or via SSH: ghe-version on the appliance. Compare to the table above. Anything not at or above the listed patched version is vulnerable.
2. Upgrade to the patched release for your line. Follow GitHub's GHES release notes for upgrade procedure. Hot patches are available for in-line upgrades; full version changes use the standard upgrade path. If you can't upgrade in-place immediately, restricting push access to a smaller set of trusted users (e.g., temporarily disabling push for low-trust accounts) reduces the exposure surface but is not a substitute for the patch.
3. Audit access logs out of an abundance of caution. Per GitHub's guidance, review /var/log/github-audit.log* for any unusual activity, particularly push operations whose push options contain unexpected special characters. The exploit relies on a semicolon (;) appearing in a push option value to break out of the X-Stat field delimiter, so semicolons in push option values are the highest-signal indicator. Example pattern to investigate: git push activity with push options containing semicolons or other unexpected delimiter-like characters.
4. If you find suspicious activity in logs, treat the instance as potentially compromised. RCE on GHES is full-server compromise, including access to all hosted repositories and internal service configuration. Engage incident response, preserve logs and disk images, and rotate every secret accessible to the instance (deploy keys, OAuth secrets, integration tokens, repository secrets, instance encryption keys per GHES procedure).
5. Once patched, verify. Confirm the appliance is running the patched version and that any required post-upgrade steps from GitHub's release notes have been completed.

If you only use github.com / GHEC

For github.com, GHEC, GHEC-DR, and GHEC-EMU users, GitHub requires no action: no patch to apply and no GitHub-directed credential rotation. The fix was deployed on March 4, 2026, and GitHub's investigation found no pre-disclosure exploitation. Organizations with separate internal risk policies can still apply their normal post-disclosure review process. The Wiz post is worth reading for the technical detail; that is the full utility of this disclosure for github.com users.

How the bug worked, in brief

A git push on GitHub flows through several internal services: babeld (the git proxy and SSH entry point), gitauth (authentication and policy lookup), gitrpcd (RPC server that trusts babeld entirely), and the pre-receive hook binary that enforces server-side policies. Those services talk to each other using an internal HTTP-style header called X-Stat, a semicolon-delimited list of key=value pairs that carries security policy for the push (file size limits, branch rules, hook configuration, environment).

Per Wiz's analysis: babeld embedded user-supplied git push option values directly into the X-Stat header without sanitizing semicolons. Because the parser used last-write-wins semantics, a semicolon-bearing push option could inject new, attacker-controlled fields that overrode the legitimate security metadata. Wiz then chained multiple injected internal metadata fields to alter the hook execution context, redirect hook lookup behavior, and reach arbitrary command execution as the git service user. The specific X-Stat fields involved in the chain (rails_env, custom_hooks_dir, and repo_pre_receive_hooks) are documented in detail in the Wiz post for readers interested in the mechanism.

On GHES, the custom-hooks code path is reachable by default and the chain works directly. On github.com, an additional flag controls whether the server runs in enterprise mode; that flag is also carried in the X-Stat header and was equally injectable. One more injected field, and the same chain executed on github.com.

What this disclosure says about the rest of the Bulletin's recent set

The other April supply-chain incidents in this Bulletin (Checkmarx KICS, Bitwarden CLI, xinference) were all abuses of CI/CD pipelines: attackers compromising or hijacking GitHub Actions, npm publishing credentials, and PyPI distribution paths to inject malicious code into otherwise legitimate releases. CVE-2026-3854 is different in kind. It is a bug in the platform itself, found and fixed before any attacker reached it, with a coordinated disclosure timeline that worked the way responsible disclosure is supposed to: report on day one, same-day fix on the public service, a week to patch enterprise releases, public disclosure two months later when patches are available and most operators have had time to apply them.

One specific element of the Wiz post worth flagging for context: Wiz attributes the speed and depth of the analysis to AI-augmented reverse engineering tooling (specifically IDA MCP), which let them reconstruct GitHub's compiled internal protocols at a pace that historically would have been impractical. The same class of tools is increasingly available to attackers as well as defenders. The right reading of this is not "AI is finding bugs faster" as a marketing line, it is "the cost of auditing closed-source binaries has dropped meaningfully in the last year, and the disclosure pipeline is what determines who gets there first."