One Git Push to RCE: Inside GitHub's CVE-2026-3854

On March 4, 2026, researchers at Wiz reported a remote code execution vulnerability in GitHub that let any authenticated user with push access (including to a brand-new repository they had just created themselves) execute arbitrary commands on GitHub's backend infrastructure with a single git push. GitHub patched GitHub.com the same day. Seven weeks later, on April 29, an estimated 88% of self-hosted GitHub Enterprise Server instances remain unpatched. 

CVE-2026-3854 is technically patched, but for thousands of organizations running self-hosted GitHub Enterprise Server, it is still open.

‍

What Happened

Wiz's security research team discovered an injection flaw in one of GitHub's internal protocols using AI-assisted code analysis. The bug allowed a standard authenticated user to inject commands into the protocol stream during a normal git push operation. No second factor of access was required, no privilege escalation step, no special tooling. A stock git client and a free GitHub account were sufficient.

The vulnerability affected the full GitHub product line:

• GitHub.com (the multi-tenant SaaS)
• GitHub Enterprise Server (self-hosted)
• GitHub Enterprise Cloud, including Cloud with Data Residency and Cloud with Enterprise Managed Users

GitHub patched GitHub.com on March 4, the same day Wiz reported the issue, and pushed an Enterprise Server fix on March 10. After the disclosure, GitHub conducted a forensic review and stated it found no evidence of exploitation in the wild prior to the patch. GitHub's own writeup of the response, including the engineering decisions behind the fix, is published at github.blog.

‍

The Attack Chain

The technical mechanic is what makes this vulnerability dangerous, and the impact differs sharply between the SaaS and the self-hosted product.

On Enterprise Server, an exploit yielded full server compromise. Because the GHES appliance hosts every repository, every secret, and every internal service for the organization that runs it, a single authenticated push from any user with any push permission gave the attacker access to all of it: source code across every team, deployment credentials, signing keys, integration secrets, and any data accessible from the appliance's internal network.

On GitHub.com, the impact was more architecturally interesting. The injection ran on shared storage infrastructure rather than on a customer-isolated container. From those shared storage nodes, an exploit could reach repositories belonging to other customers, potentially millions of public and private repos across unrelated GitHub accounts and organizations. This is the multi-tenant blast radius scenario that SaaS providers spend significant engineering effort trying to prevent: a single attacker, with no special privileges, breaking out of their tenancy and reaching every other tenant's data through the platform's own backend.

The trigger was the simplest possible primitive in the developer toolkit. There is no exotic Git operation here, no submodule trickery, no LFS edge case. Push to a repo you control, and the malicious payload reaches infrastructure that doesn't belong to you.

The full technical breakdown, including the specific protocol behavior Wiz exploited and the proof-of-concept reasoning, can be found on the Wiz research blog: GitHub RCE Vulnerability CVE-2026-3854.

‍

What to Do Now

For organizations running GitHub Enterprise Server, this is a patch-now situation if you haven't already:

• Upgrade to a patched GHES release. Any version cut on or after March 10, 2026. If you're behind on the patch cadence, this is the upgrade to fast-track.
• Review audit logs from before the patch was applied for unusual push activity, unexpected processes on the appliance, or new SSH keys added to system accounts.
• Rotate any secrets that lived on the appliance if you have reason to believe an unpatched instance was reachable by anyone outside your trust boundary. That includes CI tokens, deploy keys, integration secrets, signing keys, and any credentials stored in repository secrets.
• Audit who has push access, particularly to forks and personal namespaces. The vulnerability did not require commit access to a sensitive repo. Push to anything was enough.

For organizations on GitHub.com or GitHub Enterprise Cloud, no customer action is required for the underlying patch. GitHub has already deployed it. However:

• Review repository activity logs from the disclosure window (early March) for unexpected access, exfiltration patterns, or unusual API behavior on private repositories.
• Treat secrets stored as repository or organization secrets as you would after any platform incident. GitHub reports no evidence of exploitation, but if you have high-sensitivity tokens that have been static since before March 4, this is a reasonable trigger for rotation.

‍

The Bigger Picture

Three things are worth pulling out of this incident:

First, the patch gap on self-hosted infrastructure is the real vulnerability now. GitHub fixed the bug in days. The unpatched 88% is the live attack surface. Self-hosting GHES is a deliberate choice organizations make for compliance, data residency, or air-gap reasons, and that choice comes with the obligation to patch as fast as the SaaS does. Most don't. SOC 2's CC7.1, ISO 27001's A.8.8 (vulnerability management), and PCI DSS's 6.3.3 all have patch-cadence requirements; an instance that has been vulnerable for seven weeks is hard to defend in any of those audits.

Second, AI-assisted vulnerability research is accelerating both sides of the equation. Wiz found this bug using AI tooling, therefore so can attackers. Finding subtle injection bugs in large, mature codebases is getting cheaper and faster, and the bug class doesn't need to be new for that to matter. The exposure window is shrinking regardless of how old the vulnerability is, which means "we'll patch when we get to it" is a bigger gamble than it used to be.

Third, multi-tenant breakout matters more than single-tenant compromise. The most striking part of this CVE isn't the GHES path. Full server compromise from a privileged-protocol bug is bad but not unprecedented. The striking part is that on GitHub.com, an unprivileged user could reach across tenant boundaries via the storage layer. Any vendor whose product is "multi-tenant SaaS" and whose customers store source, secrets, or regulated data should treat this as the kind of incident that probably exists in their stack too, and should be hunting for it.

If your team is running self-hosted GitHub Enterprise Server and needs help getting patch management to a place that satisfies SOC 2 or ISO 27001 vulnerability management requirements, or if you want a penetration test that specifically looks at multi-tenant breakout in your own SaaS, Thoropass's team can help close the gap before the next CVE drops. Get in touch today.

‍