Critical RCE in GitHub.com and Enterprise Server Lets Attackers Fully Compromise Servers

Key Takeaways

• A critical remote code execution (RCE) vulnerability, CVE-2026-3854, was discovered in GitHub’s internal git infrastructure.
• The flaw allowed authenticated users to compromise backend servers and potentially access millions of private repositories on GitHub.com, and achieve full server takeover on GitHub Enterprise Server (GHES).
• Wiz researchers identified the vulnerability using AI-augmented reverse engineering techniques.
• GitHub rapidly patched GitHub.com within hours of disclosure, and patches are available for GHES, though many instances remain unpatched.

Critical RCE Flaw Exposes GitHub Servers and Repositories

A severe remote code execution (RCE) vulnerability, designated CVE-2026-3854, has been uncovered within GitHub’s core git infrastructure. This critical flaw could have enabled any authenticated user to compromise GitHub’s backend servers, potentially exposing millions of private repositories. For organizations utilizing GitHub Enterprise Server (GHES), the vulnerability presented an immediate path to full server compromise.

Discovery Method and Technical Details

The vulnerability was brought to light by researchers at Wiz, who leveraged AI-augmented reverse engineering to analyze closed-source compiled binaries. CVE-2026-3854 is categorized as an improper neutralization of special elements (CWE-77). It specifically resided in the way GitHub’s internal babeld git proxy processed user-supplied push option values.

When a user executes a git push -o command, arbitrary option strings are transmitted to the server. The core of the vulnerability lay in babeld‘s handling of these values: it copied them directly into an internal X-Stat header, which uses semicolons as field delimiters, without properly sanitizing semicolon characters present in the user-supplied input.

The downstream service, gitrpcd, then parsed this X-Stat header using a “last-write-wins” logic. This behavior allowed an attacker to inject new key-value fields simply by embedding a semicolon, followed by a desired field name and value, within a push option. Critical security-related fields, including rails_env, custom_hooks_dir, and repo_pre_receive_hooks, could all be overridden through this single injection vector.

The full escalation to RCE involved a chain of three injected fields:

• Sandbox Bypass: Injecting a non-production value for rails_env redirected the pre-receive hook binary from its default sandboxed execution path to an unsandboxed, direct execution path.
• Hook Directory Redirection: Overriding custom_hooks_dir allowed the attacker to specify an arbitrary location where the binary would search for hook scripts.
• Arbitrary Execution via Path Traversal: A carefully crafted repo_pre_receive_hooks entry, containing a path traversal payload, forced the binary to resolve and directly execute any binary on the filesystem, operating under the privileges of the git service user.

Remarkably, this exploit required no privilege escalation, specialized tools, or zero-day dependencies, relying solely on a standard git client.

Impact on GitHub.com and Enterprise Server

On GitHub Enterprise Server deployments, successful exploitation of this vulnerability resulted in a complete server compromise, granting attackers read/write access to all hosted repositories and internal secrets.

Initially, Wiz researchers observed that the custom hooks code path was inactive by default on GitHub.com. However, they subsequently discovered that an enterprise_mode boolean flag within the X-Stat header was also injectable. This allowed attackers to activate the full exploit chain on GitHub.com’s shared infrastructure. After achieving RCE on GitHub.com’s shared storage nodes, Wiz confirmed that the git service user possessed filesystem access to millions of repositories belonging to various users and organizations on those same nodes. The Wiz researchers responsibly validated this cross-tenant exposure using only their own test accounts, without accessing any third-party content, as detailed in their blog post.

This discovery is particularly significant as it represents one of the first critical vulnerabilities in closed-source binaries to be identified and exploited using AI tooling at scale. Wiz utilized IDA MCP for automated reverse engineering, which facilitated the rapid reconstruction of GitHub’s internal protocols across compiled binaries—a task that would have been prohibitively time-consuming through manual methods. This achievement signals a notable shift in the landscape of vulnerability research within complex, multi-service architectures.

GitHub’s Response and Patch Availability

GitHub received the vulnerability report on March 4, 2026. The company validated the report within hours and deployed a fix to GitHub.com by 7:00 p.m. UTC on the same day, well within their typical 6-hour response window. GitHub’s subsequent forensic investigation confirmed that no exploitation of the vulnerability occurred prior to its disclosure.

For GitHub Enterprise Server (GHES), patches are now available. GHES administrators are urged to apply these updates immediately. Affected versions and their respective fixed versions are detailed below:

At the time of disclosure, Wiz data indicated that a significant 88% of GHES instances remained unpatched. Users of GitHub Enterprise Cloud and GitHub.com do not need to take any action, as these platforms have already been remediated. Further details can be found on the GitHub Security Blog.

What You Should Do

• For GitHub Enterprise Server (GHES) Administrators: Immediately apply the available patches to update your GHES instances to a fixed version (3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4+).
• Audit Logs: Review your /var/log/github-audit.log for any push operations containing unusual or special characters within push option values, which could indicate prior exploitation attempts.
• Stay Updated: Ensure all your systems, especially those interacting with critical development infrastructure, are kept up-to-date with the latest security patches.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.