GitHub Patches Critical RCE in Git Push Pipeline Within 2 Hours

TL;DR

• Wiz researchers found a critical RCE in GitHub's git push pipeline that let any user with push access execute arbitrary commands on GitHub servers
• GitHub validated, patched github.com, and completed forensics in under 2 hours — zero exploitation detected
• The bug exploited unsanitized git push options to inject metadata and bypass sandboxing
• GHES customers must upgrade immediately to patched versions (3.14.25+ through 3.20.0+)

The Big Picture

On March 4, 2026, GitHub's bug bounty program caught what could have been a catastrophic security breach. Researchers at Wiz discovered a remote code execution vulnerability that affected every GitHub deployment model — github.com, Enterprise Cloud, and Enterprise Server. The attack surface was massive: any authenticated user with push access to any repository could execute arbitrary commands on GitHub's infrastructure with a single crafted git push command.

What makes this incident notable isn't just the severity — it's the response time. GitHub went from initial report to production fix in 115 minutes. That's not normal for critical infrastructure vulnerabilities, which typically take days or weeks to patch across distributed systems. The speed matters because this wasn't a theoretical exploit. The researchers provided a working proof-of-concept that required no special privileges beyond basic push access.

This is also a rare look inside how GitHub's internal git pipeline actually works, and where it broke. The vulnerability exposed architectural decisions that made sense in isolation but created risk when combined. For developers running their own git infrastructure or building tools that interact with git servers, the lessons here go beyond GitHub.

How It Works

The vulnerability lived in the metadata layer between GitHub's frontend git services and the backend systems that actually process pushes. When you run git push, GitHub doesn't just write your commits to disk. The operation passes through multiple internal services that handle authorization, hook execution, and repository state updates. These services communicate using an internal protocol that carries metadata about the push — things like repository type, target environment, and security context.

Git push options are a legitimate feature that lets clients send arbitrary key-value pairs to the server during a push. They're used for things like triggering CI workflows or passing deployment flags. GitHub accepted these user-supplied values and incorporated them into the internal metadata without proper sanitization. The metadata format used a delimiter character to separate fields, and that same character could appear in user input.

An attacker could inject additional metadata fields by including the delimiter in a push option value. By chaining multiple injected fields, the researchers demonstrated they could override the execution environment, bypass GitHub's sandboxing protections, and force the server to execute code in a privileged context. The exploit worked because the downstream service trusted the metadata as internally generated, not realizing parts of it came from user input.

The specific code path the exploit triggered was never used during normal github.com operations. It existed in the server's container image because it was needed for a different product configuration, but an older deployment method had correctly excluded it from production environments. When GitHub changed deployment models, that exclusion didn't carry forward. This meant the vulnerable code was present but dormant — until someone found a way to activate it through metadata injection.

What This Changes For Developers

If you're running GitHub Enterprise Server, this is a drop-everything-and-patch situation. The vulnerability requires an authenticated user with push access, which means any developer on your instance could potentially exploit it. GitHub recommends reviewing /var/log/github-audit.log for unusual push operations, particularly those with unexpected special characters in push options. The patch is available across all supported GHES versions from 3.14.25 through 3.20.0.

For github.com and Enterprise Cloud users, the fix shipped on March 4 and required no action. GitHub's forensic investigation found zero evidence of exploitation beyond the researchers' own testing. They could make that determination with confidence because the exploit forced the server down a code path that's never used in normal operations and is fully instrumented. Every execution of that path was logged and mapped back to the Wiz team's testing activity.

The broader lesson is about input sanitization at service boundaries. GitHub's vulnerability wasn't in the git protocol itself — it was in how user-supplied data crossed from the frontend service into the internal metadata layer. If you're building systems that pass user input between services, especially when that input gets embedded in structured formats like JSON, protobuf, or custom protocols, you need explicit sanitization at every boundary. Trusting that upstream services already validated the data is how injection vulnerabilities happen.

The defense-in-depth angle matters too. GitHub's primary fix was input sanitization, but they also removed the unnecessary code path from environments where it shouldn't exist. Even if a similar injection bug appears in the future, the attack surface is now smaller. If you're shipping containerized services, audit what's actually in your images versus what needs to be there for your deployment model.

Try It Yourself

This vulnerability is patched and the exploit details aren't public, so there's nothing to try. Instead, here's what you should check in your own git infrastructure:

If you run GitHub Enterprise Server: Upgrade immediately to the latest patch release for your version. Check your audit logs for any push operations with unusual characters in push options between the vulnerability window and your patch date.

If you build tools that interact with git servers: Review how you handle git push options and other user-supplied metadata. Are you sanitizing input before embedding it in structured formats? Are you validating that internal metadata fields can't be overridden by external input?

If you're on github.com or Enterprise Cloud: You're already patched. No action required. But if you're curious about GitHub's reliability track record, read our analysis of GitHub's recent reliability issues to understand how they handle incidents at scale.

The Bottom Line

Use this as a case study in incident response, not just a security patch. GitHub went from bug report to production fix in under two hours because they had the telemetry to validate the issue quickly and the deployment infrastructure to ship a fix without a multi-day release cycle. If you're running critical infrastructure, that's the bar.

Skip the hand-wringing about whether this should have been caught in code review. Complex systems have emergent vulnerabilities that aren't obvious until someone chains multiple behaviors together. The real question is whether you can detect and respond fast enough when it happens. GitHub could prove no exploitation because they logged the anomalous code path. If you can't answer "was this exploited?" with telemetry, you have a bigger problem than the vulnerability itself.

The risk here was existential — arbitrary code execution on GitHub's infrastructure with minimal privileges required. The fact that it was caught through the bug bounty program and patched before any exploitation is the best possible outcome. If you're not running a bug bounty program for your critical infrastructure, this is why you should.

Source: GitHub Blog