One Git Push Could Have Compromised Millions of Repositories: CVE-2026-3854 Explained

On March 4, 2026, the security world quietly dodged a massive bullet, though most developers wouldn't find out until late April.

Researchers at Wiz, one of the leading cloud security firms, discovered a critical remote code execution (RCE) vulnerability in GitHub's internal infrastructure. The flaw, now tracked as CVE-2026-3854 with a CVSS score of 8.7, could have allowed any authenticated GitHub user, including someone who simply created a free account, to execute arbitrary commands on GitHub's backend servers with nothing more than a standard git push command.

Millions of public and private repositories were potentially within reach.

This wasn't a theoretical attack. It was straightforward, required no special privileges beyond basic push access, and left almost no fingerprints. GitHub patched it in under two hours and, fortunately, confirmed that no one exploited it in the wild. But the story doesn't end there, as of public disclosure on April 28, 2026, 88% of GitHub Enterprise Server instances had still not been updated to a patched version.

Here's everything you need to know.

What Is CVE-2026-3854?

CVE-2026-3854 is a command injection vulnerability (classified under CWE-77: Improper Neutralization of Special Elements used in a Command) affecting GitHub's internal git infrastructure. It impacted:

• GitHub.com

• GitHub Enterprise Server (GHES)

• GitHub Enterprise Cloud

• GitHub Enterprise Cloud with Data Residency

• GitHub Enterprise Cloud with Enterprise Managed Users

In plain terms: the vulnerability lived inside the pipeline GitHub uses to process git push operations, and it stemmed from a failure to properly sanitize user-supplied input before passing it through internal services.

How the Vulnerability Worked: A Technical Breakdown

The Git Push Pipeline and babeld

When you run git push, the request doesn't go straight to a storage layer. It passes through GitHub's internal proxy, a service called babeld, which processes metadata and routes the operation to downstream services. Part of this process involves constructing an internal header called X-Stat, a semicolon-delimited string that carries security-critical configuration data between services.

Here's where the problem started.

The Injection Point: Push Options

Git allows users to pass custom "push options" using the -o flag. For example: git push -o some_option=value. These user-supplied option values are supposed to be handled safely. But GitHub's babeld proxy was copying these values verbatim into the X-Stat header, without stripping or escaping the semicolon character.

The semicolon, as it happens, is the same character used as a field delimiter in the X-Stat header format.

So by crafting a push option value that contained a semicolon followed by additional fields, an attacker could inject entirely new metadata fields into the header, fields that downstream services would then read and trust as legitimate configuration data.

As GitHub's own advisory described it: "During a git push operation, user-supplied push option values were not properly sanitized before being included in internal service headers. Because the internal header format used a delimiter character that could also appear in user input, an attacker could inject additional metadata fields through crafted push option values."

Escalating to Full RCE: The rails_env Bypass

The injection alone was bad. But the researchers took it further. By injecting specific fields, they could manipulate a value called rails_env in the header. On GitHub Enterprise Server, this flag controls whether custom Git hooks run in a sandboxed environment or not.

By altering rails_env to disable sandbox protections, and then using path traversal to redirect the hooks directory, the attackers could force the server to execute arbitrary files. The result: full, unsandboxed remote code execution as the git user on the GHES instance.

As Wiz researcher Sagi Tzadik described it: with unsandboxed code execution as the git user, they had full control over the GHES instance, including filesystem read/write access and visibility into internal service configuration.

The GitHub.com Dimension: Cross-Tenant Exposure

The situation on GitHub.com was different but arguably even more alarming from a scale perspective.

On GitHub.com, the enterprise mode flag that enables the custom hooks path defaults to "false." But because this flag is also passed through the injectable X-Stat header, the same injection mechanism could force it to "true," triggering code execution on GitHub.com's backend storage nodes as well.

And here's where "millions of repositories" enters the picture. GitHub's infrastructure uses shared storage nodes that serve multiple users and organizations simultaneously. Gaining code execution on one of these nodes meant access to the data of any repository stored on that node, regardless of which user or organization owned it.

Wiz confirmed that millions of public and private repositories were accessible on the affected nodes, though the researchers stated clearly that they did not access any other tenants' actual data.

Who Discovered It, And How AI Was Involved

The vulnerability was discovered by a team of six researchers at Wiz Research: Sagi Tzadik, Nir Ohfeld, Ronen Shustin, Hillai Ben-Sasson, Yuval Avrahami, and Noam Malron.

What makes this discovery particularly notable is how they found it. GitHub's infrastructure includes closed-source compiled binaries, code that isn't publicly readable, making vulnerability research significantly harder. The Wiz team used IDA MCP, an AI-augmented reverse engineering tool, to analyze these binaries and reconstruct GitHub's internal protocols without access to source code.

This represents a meaningful shift in how security research is conducted. Previously, auditing opaque, multi-service architectures like GitHub's would have been prohibitively time-consuming manually. AI-assisted tooling compressed that timeline dramatically.

It also signals something important for the broader security community: if white-hat researchers can leverage AI to find critical flaws in closed-source infrastructure faster, so can malicious actors.

Timeline: Discovery to Disclosure

GitHub's response speed here deserves credit. From the moment they received the report, they validated the finding, deployed a fix to GitHub.com, and launched a forensic investigation, all within two hours. GitHub CISO Alexis Wales called the finding rare and confirmed it would receive one of the highest bug bounty rewards in the platform's history.

Impact Scope: Who Was Affected?

GitHub.com Users

For users of the public GitHub.com platform, the vulnerability has been fully remediated. No action is required. GitHub's forensic investigation confirmed zero exploitation in the wild, every instance of the anomalous code path triggered in telemetry mapped back to the Wiz researchers' own testing.

GitHub Enterprise Server (GHES) Customers

This is where the urgency remains. GHES customers are responsible for managing their own server updates. Patches were released on March 10, 2026, across all supported versions:

• 3.14.25

• 3.15.20

• 3.16.16

• 3.17.13

• 3.18.8

• 3.19.4

• 3.20.0 or later

As of April 28, 2026, the date of public disclosure, 88% of GHES instances had not been updated. This is critical. Now that technical details are public, the attack surface for unpatched GHES instances is fully exposed.

GitHub Enterprise Cloud (including Data Residency and EMU)

These environments are managed by GitHub directly and have been patched. No action required for customers on these plans.

The Wider Lesson: Multi-Service Architecture and Injection Risk

Wiz was deliberate in pointing out that this vulnerability isn't just a GitHub problem, it's a pattern that appears across complex, multi-service systems.

When services written in different languages communicate through a shared internal protocol, each service makes implicit assumptions about the data it receives. In this case, one service assumed that push option values were safe to embed directly into a structured format. Another service downstream trusted those embedded values as legitimate configuration.

The assumption gap between "input is safe" and "data is trusted configuration" is the attack surface.

As Wiz put it: "We encourage teams building multi-service architectures to audit how user-controlled input flows through internal protocols, especially where security-critical configuration is derived from shared data formats."

This is a lesson that applies to virtually every modern SaaS platform, cloud-native application, and microservices architecture built today.

What Should You Do Right Now?

If you use GitHub.com: You're already protected. No action needed.

If you use GitHub Enterprise Cloud (any variant): Already patched by GitHub. No action needed.

If you run GitHub Enterprise Server:

1. Upgrade immediately to one of the patched versions listed above (3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 or later).

2. Audit your logs. Review /var/log/github-audit.log for push operations containing unusual special characters, particularly semicolons, in push option values.

3. Treat this as a fire drill. The technical details are now public. Unpatched instances are a live target.

For security and DevSecOps teams more broadly:

• Audit how user-controlled input flows through your internal service protocols.

• Review delimiter handling in any custom protocol formats your services use.

• Ensure input sanitization is enforced at every service boundary, not assumed from upstream.

Conclusion

CVE-2026-3854 is a reminder that critical infrastructure, even the most widely trusted platforms in the developer ecosystem, can contain severe vulnerabilities hiding in plain sight inside internal protocols. A semicolon. An unsanitized string. A single git push. That was all it took to theoretically expose millions of repositories.

The good news is that responsible disclosure worked exactly as it should. Wiz reported the issue. GitHub responded with exceptional speed. A forensic investigation confirmed no exploitation. Patches were released across all supported versions.

The lingering concern is the 88% of GitHub Enterprise Server instances that remain unpatched as of disclosure. If your organization runs GHES, this is not the vulnerability to deprioritize.

Patch now. Audit your logs. And take Wiz's broader architectural advice seriously, because CVE-2026-3854 is a pattern, not just a bug.

Sources: Wiz Research, GitHub Security Blog, The Hacker News, Security Affairs, CyberSecurityNews