Git Push Leads to RCE on GitHub
On April 28, 2026, Wiz Research and GitHub disclosed details of CVE-2026-3854: a command-injection vulnerability in GitHub Enterprise Server that allows any authenticated user with push access to a repository to execute arbitrary code on the server with a single git push.
6 min read
Key Takeaways
- CVSS 8.7 – one
git pushis all it takes. Any user with push access to a repository—even one they created—can execute arbitrary commands on the GitHub Enterprise Server. No exploit kit, just a standard Git client. - Command-injection in push-option handling. Push-option values were not sufficiently sanitized before processing. An attacker can inject additional metadata fields into internal service headers via a delimiter character.
- GitHub.com was patched within hours. Wiz Research discovered the flaw on March 4, 2026, and reported it to GitHub the same day. Patch on GitHub.com: March 4. GHES patches: March 10. Public disclosure: April 28, 2026.
- Patches available for all supported GHES versions. 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0 and higher. Older versions no longer receive support.
How the Attack Works: Why a git push Leads to RCE
Git push operations support so-called push options—custom key-value pairs that pass metadata with the push. GitHub Enterprise Server processed these values in an internal protocol without sufficiently escaping the delimiter character. Because this delimiter can appear in user input, crafted push-option values can inject additional header fields into the internal communication.
The result is code execution on the server—not in the repository layer, but in the backend service that processes the push. Wiz Research notes the attack is fully reproducible with a standard Git client. No special tooling, no pre-existing vulnerability, no elevated authorization beyond push access to a repository.
The attack scenario thus has a low barrier to entry: any external contributor, any employee with repository access, or any compromised account can exploit this flaw. In enterprise environments with large-scale self-hosted GitHub deployments, the attack radius is substantial.
Disclosure Timeline: What Happened Between March and April
March 4, 2026: Wiz Research discovers and responsibly reports the flaw to GitHub. GitHub deploys a fix on GitHub.com within hours.
March 10, 2026: Patches for all supported GitHub Enterprise Server versions are released: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0. CVE-2026-3854 is assigned CVSS 8.7.
April 28, 2026: Public disclosure following coordinated vulnerability disclosure. At this point, Help Net Security research shows 88 percent of self-hosted instances remain unpatched—nearly seven weeks after fixes were available.
88 percent unpatched. Seven weeks after the GHES patch, nearly every self-hosted instance still runs the vulnerable version. This isn’t an outlier—it’s the norm in enterprise Git infrastructure.
What Security Teams in the DACH Region Need to Do Right Now
1. Check your GHES version immediately. Currently patched minimum versions: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, 3.20.0. Any version below or prior to 3.14 is unsupported and requires an upgrade.
2. Audit repository access rights. Who has push access to which repositories? External contributors, outdated service accounts, temporary credentials? Each of these accounts represents a potential attack vector—regardless of whether the repository is public or internal.
3. Review server logs for anomalies. GitHub provides logging for push operations. Unusual push option values, pushes from unknown IP addresses, or activity at atypical times should be escalated for manual review.
4. Verify network-layer controls. The GHES admin port (8443) and internal service endpoints should not be exposed to the public internet. This doesn’t eliminate risk entirely, but raises the barrier for external attackers.
Frequently Asked Questions About CVE-2026-3854
Does CVE-2026-3854 affect GitHub.com or only self-hosted instances?
Both were impacted. GitHub.com deployed a fix within hours of Wiz Research’s responsible disclosure on March 4, 2026. Users of GitHub.com have been protected since then. The risk remains solely with organizations running their own GitHub Enterprise Server instances that haven’t yet upgraded to the patched versions.
Should all repositories on a GHES server be considered compromised?
That depends on whether the vulnerability was actively exploited. A patch closes the attack vector but doesn’t remediate prior compromise. Organizations with sensitive code—infrastructure-as-code, credentials in repositories, CI/CD pipeline configurations—should inspect Git history and server logs for suspicious activity since March 2026. When in doubt: initiate your incident response process.
Can GitHub Actions or CI/CD pipelines exploit the vulnerability?
Yes. Any automated component executing Git push operations—Actions workflows, CI/CD runners, deployment scripts—becomes a potential attack vector if running on a vulnerable GHES instance. Of particular concern: external runners with access to multiple repositories, especially if their credentials may have been compromised.
How does this differ from the supply-chain vulnerability in the Bitwarden CLI GitHub Action?
CVE-2026-3854 is a server-side vulnerability—the attack targets the GitHub Enterprise Server itself. The Bitwarden CLI GitHub Action flaw is a supply-chain attack via external dependencies in pipelines. Both are critical, but require different mitigations: patch management for CVE-2026-3854, dependency pinning and SBOM processes for supply-chain risks.
Editor’s Reading Picks
More from the MBF Media Network
Source of title image: Pexels / Markus Spiske (px:1089438)
