Securing GitHub: Wiz Research uncovers Remote Code Execution in GitHub.com and GitHub Enterprise Server (CVE-2026-3854)
Pangram verdict · v3.3
We believe that this document is a mix of AI-generated, and human-written content
AI likelihood · overall
MixedArticle text · 1,650 words · 5 segments analyzed
Wiz Research uncovered a critical vulnerability (CVE-2026-3854) in GitHub's internal git infrastructure that could have affected both GitHub.com and GitHub Enterprise Server. By exploiting an injection flaw in GitHub's internal protocol, any authenticated user could execute arbitrary commands on GitHub's backend servers with a single git push command - using nothing but a standard git client.Notably, this is one of the first critical vulnerabilities discovered in closed-source binaries using AI, highlighting a shift in how these flaws are identified. Despite the complexity of the underlying system, the vulnerability is remarkably easy to exploit. On GitHub.com, this vulnerability allowed remote code execution on shared storage nodes. We confirmed that millions of public and private repositories belonging to other users and organizations were accessible on the affected nodes. On GitHub Enterprise Server, the same vulnerability grants full server compromise, including access to all hosted repositories and internal secrets.GitHub mitigated this issue on GitHub.com within 6 hours of our report, released patches for all supported versions of GitHub Enterprise Server, and published the CVE at the time of release. GitHub Enterprise Server customers should upgrade immediately - at the time of this writing, our data indicates that 88% of instances are still vulnerable. Detailed remediation steps and further technical details are available in GitHub’s security blog post.GitHub greatly appreciates the collaboration, professionalism, and partnership that Wiz has shown throughout this process. A finding of this caliber and severity is rare, earning one of the highest rewards available in our Bug Bounty program, and serves as a reminder that the most impactful security research comes from skilled researchers who know how to ask the right questions. As the landscape evolves, these close partnerships with talented hunters and researchers are more important than ever.Alexis Wales, GitHub CISOThis post breaks down the vulnerability, walks through the exploitation chain, and provides recommendations for GHES administrators to protect their environments.Figure: Vulnerability overview - a single git push compromises GitHub's internal infrastructureRequired Actions and MitigationsGitHub.com: GitHub has mitigated this issue. No action is required for GitHub.com users.GitHub Enterprise Server: Immediate action required.
Upgrade to GHES version 3.19.3 or later - this release patches CVE-2026-3854Affected VersionsComponentVulnerable VersionsFixed VersionGitHub Enterprise Server<= 3.19.13.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6 and 3.19.3Find Vulnerable GHES Instances with WizWiz customers can identify vulnerable GitHub Enterprise Server instances in their environments using this pre-built query in the Wiz Threat Center. The query identifies all GHES instances running a version vulnerable to this issue.Figure: Wiz Threat Center query for vulnerable GHES instancesWhy We Researched GitHub's Git InfrastructureGitHub is the world's largest code hosting platform, home to hundreds of millions of repositories spanning open source projects, enterprise codebases, and critical infrastructure. Its internal git infrastructure-the pipeline that processes every git push-is one of the most security-sensitive systems on the internet. When a user pushes code, it passes through multiple internal services, each written in a different programming language. This multi-service architecture creates opportunities for inconsistencies in how each component parses and trusts shared data.We've looked into GitHub Enterprise Server (GHES) in the past to hunt for these exact types of vulnerabilities. However, extracting and auditing the sheer volume of compiled blackbox binaries that run this pipeline historically required an impractical amount of time and manual effort.But this is Round 2, and the landscape has shifted. By leveraging AI-augmented tooling-particularly automated reverse engineering using IDA MCP-we were able to do what was previously too costly. Using AI, we rapidly analyzed GitHub's compiled binaries, reconstructed internal protocols, and systematically identified where user input could influence server behavior across the entire pipeline. Thanks to this new capability, we found a fundamental flaw in how that input flows through GitHub's multi-service architecture.Technical Deep-DiveUnderstanding the ArchitectureWhen a user runs git push against GitHub via SSH, the request flows through several key components:babeld - A git proxy and the entry point for all git operations.
It receives the user's SSH connection and forwards authentication to gitauth.gitauth - An internal authentication service. It verifies the user's credentials, checks whether they have push access to the target repository, and returns the security policies that apply to the session - file size limits, branch naming rules, and more. babeld takes this response and constructs an internal header containing all of this security metadata.gitrpcd - An internal RPC server. It receives the request from babeld, parses the X-Stat header, and sets up the environment for downstream processes. Critically, gitrpcd performs no authentication of its own - it trusts babeld completely and treats every field in the X-Stat header as authoritative.The pre-receive hook - A compiled Go binary that enforces security policies before a push is accepted. It checks file size limits, branch naming rules, LFS integrity, and runs any admin-defined custom hooks.The critical link between these components is the X-Stat header. It carries security-critical fields as semicolon-delimited key=value pairs. Internal services parse this header by splitting on ; and populating a map. A key detail: the map uses last-write-wins semantics. If a key appears twice, the later value silently overrides the earlier one.When babeld forwards a push request, one of the internal requests includes push options in the X-Stat header. Git push options are arbitrary strings that users can pass with git push -o. They are a standard git protocol feature, intended for server-side hints. babeld encodes them as numbered fields - push_option_0, push_option_1, and so on - alongside a push_option_count.Figure: GitHub internal git push pipelineThe Vulnerability: X-Stat Field InjectionSo what happens when user-controlled input reaches the X-Stat header without proper sanitization?babeld copies git push option values directly into the X-Stat header - without sanitizing semicolons. Since ; is the X-Stat field delimiter, any semicolon in a push option value breaks out of its designated field and creates new, attacker-controlled fields.Consider a push option value that contains a semicolon followed by a security field name.
babeld embeds it verbatim, producing a header like:When splitting on ;, this header parses as:The attacker's value wins because it appears later in the header - last-write-wins.We confirmed this both through binary analysis and on the wire - a packet capture on a live GHES instance showed injected fields appearing alongside and overriding their legitimate counterparts in the X-Stat header.By combining reverse engineering of the pre-receive binary with wire-level analysis, we mapped out injectable X-Stat fields. The following are particularly security-relevant:FieldPurposerails_envControls hook execution path (sandbox vs. direct exec)custom_hooks_dirBase directory for custom hook script lookuprepo_pre_receive_hooksJSON definitions of pre-receive hooks to executelarge_blob_rejection_enabledEnforces file size limitsreject_sha_like_refsBlocks SHA-like branch namesuser_operator_modeEnables internal debug outputThe first three are the ones that matter most - together, they lead to remote code execution.Escalation to RCEOverriding security flags like large_blob_rejection_enabled is interesting, but the real question is: can we turn field injection into code execution?The answer lies in three fields from the table above: rails_env, custom_hooks_dir, and repo_pre_receive_hooks. To understand why, we need to look at how the pre-receive hook binary handles custom hooks.GHES supports admin-defined custom pre-receive hooks - scripts that run before a push is accepted. By reverse engineering the pre-receive binary, we discovered it has two execution paths, controlled entirely by the rails_env field from the X-Stat header: a production value that runs hooks inside a sandbox, and any other value that runs hooks directly - no sandbox, no isolation - as the git service user with full filesystem access.The only thing separating these two paths is the value of rails_env. And we can inject it.The escalation to RCE chains three injections together:Step 1 - Bypass the sandbox. Inject a non-production rails_env value to switch from the sandboxed production path to the unsandboxed path.Step 2 - Redirect the hook directory. Inject custom_hooks_dir to control the base directory where the binary looks up hook scripts.Step 3 - Inject a hook definition with path traversal.
Inject repo_pre_receive_hooks with a crafted hook entry whose script field contains a path traversal sequence. The binary's path resolution joins the attacker- controlled base directory with the traversal payload, resolving to an arbitrary binary on the filesystem.The non-production path then executes the resolved path directly - no arguments, no sandbox - as the git service user:With unsandboxed code execution as the git user, we had full control over the GHES instance, including filesystem read/write access and visibility into internal service configuration.From GHES to GitHub.comWe had RCE on GitHub Enterprise Server. The next question was obvious - does this work on GitHub.com?We ran the same exploitation chain against a repository on GitHub.com. The push completed successfully, but the custom hooks never executed. No remote: output, no code execution - nothing.To understand what was happening, we injected user_operator_mode=bool:true to enable debug output on both platforms. Comparing the output side by side, we noticed that GitHub.com was missing certain hook execution steps that appeared on GHES - the custom hooks code path was simply not being reached.We went back to the binary and dug deeper. Through further reverse engineering, we identified a boolean flag in the X-Stat header that controls whether the server operates in enterprise mode. On GHES, this flag defaults to true - so the custom hooks path is always active. On GitHub.com, it defaults to false, meaning custom hooks are never reached under normal conditions.Since this flag was also carried in the X-Stat header, it was injectable through the same mechanism. One more injected field, and the full exploitation chain worked on GitHub.com. This time, we executed hostname instead of id:RCE on GitHub.com - confirmed.Cross-Tenant ImpactRCE on GitHub Enterprise Server is a critical vulnerability. On GitHub.com, the same flaw had broader implications due to the shared infrastructure serving multiple users and organizations.GitHub.com is a multi-tenant platform. Repositories belonging to millions of different organizations and users are stored on shared backend infrastructure. When we achieved code execution on GitHub.com, we landed on a shared storage node running as the git user.The git user exists for a reason: it serves all repository operations across the node. By design, it has broad filesystem access to every repository hosted on that node.