CVE-2026-3854 Allows Remote Code Execution Vulnerability in GitHub’s Infrastructure

In a striking demonstration of how microservice communication can become a primary attack vector, Wiz Research has uncovered a critical Remote Code Execution (RCE) vulnerability within GitHub’s core git infrastructure. Tracked as CVE-2026-3854, this high-severity flaw allows any authenticated user to execute arbitrary commands on backend servers through a standard, seemingly benign git push command.

The Root Cause: Delimiter Injection in Internal Metadata

The vulnerability is not found in the git protocol itself, but rather in how GitHub’s internal architecture handles transit metadata. To maintain state across its distributed services, GitHub utilizes an internal HTTP header named X-Stat to pass security-critical configuration settings between services.

The breakdown occurs at the entry point: a service known as babeld. When a user initiates a push, babeld captures git push options and copies them into the X-Stat header. However, the service failed to sanitize semicolon (;) characters within these options. Because X-Stat uses semicolons as field delimiters, an attacker can “break out” of a legitimate field and inject their own metadata. As reported by Wiz, this creates a significant logic flaw in how downstream services parse security policies.

The internal parsing mechanism follows a “last-write-wins” logic. This means that if an attacker injects a duplicate field at the end of the header string, it silently overrides the legitimate, secure values originally set by the authentication service.

Affected Component Vulnerable Versions Patched/Fixed Versions
GitHub Enterprise Server (GHES) 3.19.1 and older 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4

The Attack Chain: From Injection to Full System Compromise

Exploiting this vulnerability isn’t a one-step process; it requires a sophisticated “triple-threat” injection chain to bypass modern sandboxing and achieve code execution:

  • Environment Manipulation: Attackers inject a non-production rails_env value. This tricks the backend into exiting its hardened security sandbox, enabling the execution of custom pre-receive hooks.
  • Directory Redirection: By injecting a malicious custom_hooks_dir, the attacker instructs the server to look for executable hook scripts in a directory of the attacker’s choosing.
  • Path Traversal Execution: Finally, a crafted repo_pre_receive_hooks definition—utilizing path traversal sequences—points the server toward arbitrary binaries on the filesystem to be executed.

Once the chain is complete, the injected code runs with the privileges of the internal git service user. For organizations running GitHub Enterprise Server (GHES), this represents a total loss of control, potentially exposing all hosted repositories, system secrets, and internal configurations.

Vulnerability overview diagram
Visualizing the vulnerability flow (Source: Wiz)

The Multi-Tenant Risk and AI-Driven Discovery

On the public GitHub.com platform, the implications are even broader due to the multi-tenant architecture. A successful exploit allows an attacker to gain filesystem access to shared storage nodes. This could theoretically allow a single malicious actor to read millions of repositories belonging to thousands of different organizations sharing that specific node.

Interestingly, the discovery of this flaw highlights a new frontier in cybersecurity. Because GitHub’s architecture relies on vast numbers of compiled, “blackbox” binaries, manual reverse-engineering is nearly impossible. The Wiz researchers bypassed this hurdle using AI-augmented automated reverse-engineering tools, specifically IDA MCP, to reconstruct the internal communication protocols. This marks a significant shift where AI is becoming an essential tool for uncovering complex, cross-component vulnerabilities in closed-source environments.

Wiz Threat Center query for vulnerable GHES instances
Wiz Threat Center identifying vulnerable GHES instances (Source: Wiz)

Remediation Strategy

GitHub has already mitigated the risk on the public GitHub.com platform, responding within six hours of the report. However, for organizations managing self-hosted environments, immediate action is mandatory. Because the attack requires only network access to a single repository via a push command, patching your GitHub Enterprise Server to the versions listed in the table above is the only way to ensure protection.

Related Articles

Back to top button