Github RCE Vulnerability

Published: April 30, 2026 | Category: Vulnerability Research | Reading Time: ~8 min
Tags: CVE-2026-3854 · GitHub Security · Remote Code Execution · GitHub Enterprise Server · Wiz Research

TL;DR: A critical injection flaw in GitHub's internal git pipeline allowed any authenticated user to execute arbitrary code on GitHub.com's shared infrastructure and fully compromise self-hosted GitHub Enterprise Server — using nothing but a standard git push command. The flaw was discovered by Wiz Research, patched by GitHub within 6 hours, and assigned a CVSS score of 8.8 (HIGH). If you run GitHub Enterprise Server, upgrade immediately.

A high-level diagram showing the git push pipeline (babeld → gitauth → gitrpcd → pre-receive hook). Label each component. Alt text: "GitHub internal git push pipeline showing CVE-2026-3854 attack path

What Happened?

On March 4, 2026, security researchers at Wiz Research reported a critical vulnerability to GitHub through its Bug Bounty program. The flaw — now tracked as CVE-2026-3854 — lived inside GitHub's internal git processing pipeline, and its implications were severe.

Any authenticated GitHub user — someone with push access to even their own repository — could craft a single git push command to:

  • Execute arbitrary code on GitHub.com's shared backend storage nodes
  • Potentially access millions of private repositories belonging to other users and organizations
  • Fully compromise a self-hosted GitHub Enterprise Server instance, including all secrets and internal configuration

What made this particularly alarming was the simplicity. No special tools. No elevated permissions. Just a standard git client and a crafted push option.

GitHub responded swiftly, deploying a fix to GitHub.com within 6 hours of the report. However, at the time of public disclosure on April 28, 2026, Wiz's data indicated that approximately 88% of GitHub Enterprise Server instances were still unpatched.

CVE Details at a Glance

Field Details
CVE ID CVE-2026-3854
CVSS Score 8.8 HIGH
CVSS Vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CWE CWE-77 — Command Injection
Affected Product GitHub Enterprise Server ≤ 3.19.3
Reported By Wiz Research
Reported On March 4, 2026
Patched (GitHub.com) March 4, 2026
CVE Published March 10, 2026
Public Disclosure April 28, 2026

The official NVD description classifies this as an improper neutralization of special elements — meaning user-supplied input was embedded into an internal service protocol without proper sanitization, allowing an attacker to inject and override security-critical fields.

Understanding the Architecture: Where the Bug Lives

To understand the vulnerability, you first need to understand what happens when you run git push on GitHub.

A flowchart or architecture diagram showing: User → SSH → babeld → gitauth → gitrpcd → pre-receive hook. Highlight the X-Stat header passing between babeld and gitrpcd. Alt text: "Architecture diagram of GitHub git push components involved in CVE-2026-3854

GitHub's git pipeline involves four key components:

1. babeld — The entry point. It receives all SSH-based git operations and forwards authentication to the next service.

2. gitauth — Verifies credentials, checks push access, and returns security policies (file size limits, branch rules, etc.) back to babeld. babeld then packages all of this metadata into an internal header called the X-Stat header.

3. gitrpcd — Receives the request from babeld and parses the X-Stat header to set up the environment for downstream processes. Critically, it performs no authentication of its own — it trusts babeld completely.

4. The pre-receive hook — A compiled Go binary that enforces security policies before accepting a push. It handles file size limits, branch rules, LFS integrity, and custom admin hooks.

The X-Stat header carries all security configuration as semicolon-delimited key=value pairs. If a key appears twice, the last value wins (last-write-wins semantics). That detail becomes the crux of the entire attack.

The Vulnerability: X-Stat Field Injection

Here's where things go wrong.

Git supports a feature called push options — arbitrary strings a user can pass to the server via git push -o. babeld encodes these push options into the X-Stat header as fields like push_option_0=<value>.

The problem: babeld did not sanitize semicolons in push option values. Since ; is the X-Stat field delimiter, an attacker could embed a semicolon in their push option value to break out of the intended field and inject entirely new fields.

For example, a crafted push option like x;large_blob_rejection_enabled=bool:false would result in the header being parsed as two fields:

  • push_option_0 = x
  • large_blob_rejection_enabled = bool:false ← injected, overrides the legitimate value

The injected value wins because it appears later in the header. What looks like a simple git push option quietly rewrites the server's security configuration.

From Injection to Remote Code Execution

Bypassing a file size limit flag is noteworthy. But Wiz's researchers went further — all the way to full remote code execution. The escalation required chaining three injections together.

Step 1 — Bypass the sandbox
The pre-receive hook binary checks a field called rails_env. In production, this value triggers a sandboxed hook execution path. By injecting a non-production value for rails_env, the attacker switches to an unsandboxed execution path — no isolation, full filesystem access as the git service user.

Step 2 — Redirect the hook directory
By injecting custom_hooks_dir, the attacker controls the base directory where the binary looks for hook scripts.

Step 3 — Execute arbitrary code
By injecting repo_pre_receive_hooks with a crafted hook entry containing a path traversal sequence, the attacker can point the binary to any executable on the filesystem. The binary then runs it directly — no arguments, no sandbox — as the git service user.

The result in practice looks like this (from Wiz's report):

remote: uid=500(git) gid=500(git) groups=500(git)   ← RCE as the git service user

One git push. Full code execution.

What About GitHub.com?

Wiz's researchers initially found that the same exploit didn't work on GitHub.com — the custom hooks code path simply wasn't reached. That's because GitHub.com disables certain enterprise-specific features by default, including custom hooks.

But here's the twist: the feature toggle controlling this behavior was itself part of the X-Stat header — and therefore also injectable. By adding one more injected field to re-enable the enterprise code path, the full exploit chain worked on GitHub.com too.

remote: ██████████████████████████.github.net   ← inside GitHub.com infrastructure

RCE on GitHub.com — confirmed.

Cross-Tenant Exposure: The Bigger Picture

GitHub.com is a multi-tenant platform. When Wiz's researchers achieved code execution on a shared storage node, they landed as the git service user — an account that, by design, has read access to all repositories on that node to serve git operations.

From just two compromised nodes, the researchers found entries for millions of repositories belonging to unrelated users and organizations.

To be clear: Wiz did not access any third-party repository contents. They used their own test accounts to confirm the exposure was theoretically possible, and reported responsibly. But the implication is stark — a malicious actor exploiting this before the patch could have silently read private codebases across the entire platform.

GitHub's Response

GitHub's response was notably fast and thorough. According to GitHub's security blog:

  • 40 minutes after receiving the report, the vulnerability was internally reproduced and severity confirmed
  • ~2 hours after the report, a fix was deployed to GitHub.com and a forensic investigation was underway
  • The investigation confirmed no exploitation occurred — the exploit forces a code path never used in normal operations, making it detectable in telemetry. Every instance of that anomalous path mapped exclusively to Wiz's own testing activity

GitHub also noted a secondary finding worth highlighting: the exploit worked partly because a non-production code path existed in the production server's container image — a leftover from a previous deployment model. GitHub has since removed that code path from environments where it doesn't belong, adding a second layer of defense even against future injection vulnerabilities.

Patched Versions & What You Need to Do

GitHub.com, GitHub Enterprise Cloud, and all hosted variants: Already patched on March 4, 2026. No action required.

GitHub Enterprise Server (GHES): You must upgrade. Patched versions:

Branch Patched Version
3.14.x 3.14.25 or later
3.15.x 3.15.20 or later
3.16.x 3.16.16 or later
3.17.x 3.17.13 or later
3.18.x 3.18.7 or later
3.19.x 3.19.4 or later
3.20.x 3.20.0 or later

Additionally, GitHub recommends reviewing /var/log/github-audit.log for any push operations containing ; in push options as a precautionary measure.

AI's Role in Finding This Vulnerability

This discovery also marks a meaningful shift in how security research is done. Wiz's team leveraged AI-augmented reverse engineering — specifically IDA MCP — to analyze closed-source compiled binaries at a scale that would have been impractical manually. Using these tools, they were able to reconstruct internal protocols, identify trust boundaries, and trace how user input propagated across the entire pipeline.

As these AI-assisted tools mature, researchers expect to find more vulnerability classes that require deep cross-component analysis — vulnerabilities that traditional manual auditing would miss or take months to surface. This is likely not the last time we see a critical flaw discovered through this methodology.

Responsible Disclosure Timeline

Date Event
March 4, 2026 Wiz Research discovers and confirms RCE on GHES 3.19.1
March 4, 2026 Vulnerability reported to GitHub via Bug Bounty
March 4, 2026 GitHub acknowledges, reproduces, and deploys fix to GitHub.com
March 10, 2026 CVE-2026-3854 assigned (CVSS 8.8); GHES patches released
April 28, 2026 Public coordinated disclosure
April 29, 2026 GitHub blog post updated with additional detail

Credit & Acknowledgments

Full credit for the discovery and responsible disclosure of CVE-2026-3854 goes to the Wiz Research Team:

This vulnerability earned one of the highest rewards in the history of GitHub's Bug Bounty program, which has run for over a decade. GitHub CISO Alexis Wales publicly praised the collaboration, calling the finding rare and underscoring the value of the security research community.

Key Takeaways for Security Teams

This vulnerability is a textbook case of how individual design decisions — each reasonable in isolation — combine into a critical flaw in multi-service architectures:

  • User input flowed into an internal protocol without sanitization
  • One service trusted another's metadata without independent verification
  • A non-production code path existed in a production environment
  • Security-critical configuration was derived from a delimiter-based format with no escaping

If your organization runs self-hosted GitHub Enterprise Server, upgrade now. If you build internal multi-service systems, audit how user-controlled input flows through shared internal protocols — especially where security configuration is derived from that data.

References

  1. Wiz Research — Securing GitHub: Wiz Research uncovers Remote Code Execution in GitHub.com and GitHub Enterprise Server (CVE-2026-3854)
  2. GitHub Security Blog — Securing the git push pipeline: Responding to a critical remote code execution vulnerability
  3. The Cyber Security Hub™ on LinkedIn — Major Security Flaw In GitHub Enables Remote Code Execution Across Millions of Repositories
  4. NVD / NIST — CVE-2026-3854 Detail
  5. GitHub Enterprise Server Release Notes — 3.19.4 Patch Notes

This blog was written for educational and informational purposes. KodeSec does not condone unauthorized testing or exploitation of vulnerabilities. Always follow responsible disclosure practices.