CVE-2026-3854: 
GitHub Enterprise Server vulnerability analysis and mitigation

CVE-2026-3854 is a command injection vulnerability in GitHub Enterprise Server (GHES) that allows an attacker with push access to a repository to achieve remote code execution on the instance. 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. The vulnerability affects GHES versions prior to 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, and 3.19.4. It was reported via the GitHub Bug Bounty program and disclosed on March 10, 2026. The CVSS v3.1 base score is 8.8 (High) and the CVSS v4.0 base score is 8.7 (High) (GitHub Release Notes 3.14, GitHub Release Notes 3.15, Feedly).

The root cause is classified as CWE-77 (Improper Neutralization of Special Elements used in a Command — Command Injection). The vulnerability resides in the babeld git proxy service, which processes git push operations on GHES. When a user supplies push options (e.g., git push -o key=value), these values are passed unsanitized into internal service headers that use a delimiter character (reportedly a semicolon) also valid in user input. By crafting push option values containing the delimiter, an attacker can inject additional header fields, overriding internal metadata and causing the server to execute arbitrary commands. The attack requires only network access and push-level repository permissions — no user interaction is needed. Wiz Research, which discovered and reported the vulnerability, used AI-assisted analysis to identify the injection point in the git push pipeline (GitHub Blog, Wiz Research).

Successful exploitation grants an attacker arbitrary code execution on the GHES instance with the privileges of the service account running the git proxy. This results in complete compromise of confidentiality, integrity, and availability — an attacker can read all hosted repository data (including private repositories), modify or destroy data, and disrupt service availability. Because GHES instances typically host source code, CI/CD secrets, and deployment credentials for entire organizations, exploitation could enable lateral movement into downstream infrastructure, supply chain attacks, and exfiltration of sensitive intellectual property. Reports indicate that approximately 88% of on-premise GHES instances were unpatched at the time of public disclosure (Wiz Research, Security Affairs).

Multiple public proof-of-concept repositories have been published on GitHub (e.g., LACHHAB-Anas/Exploit_CVE-2026-3854, lysophavin18/CVE-2026-3854-PoC, ridhinva/CVE-2026-3854-GHE-RCE), and exploit code has been indexed on Vulners and Sploitus. Exploitation has been reported in the wild by multiple sources, including undercodetesting.com. The EPSS score is approximately 0.0034 (0.34%), and as of the time of this report, the vulnerability has not been added to the CISA KEV catalog. No specific threat actor attribution has been publicly confirmed. The vulnerability requires only push access to a repository — a low privilege level — and no user interaction, making it highly accessible to insider threats and compromised developer accounts (Feedly, Wiz Research, BleepingComputer).

1. Reconnaissance: Identify a target GitHub Enterprise Server instance (versions prior to 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, or 3.19.4) using network scanning or Shodan. Confirm the version via the GHES management console or API endpoint /api/v3/meta.
2. Obtain push access: Acquire push access to any repository on the target instance — this could be through a legitimate account, a compromised developer credential, or a social engineering attack.
3. Clone the target repository: Run git clone <ghes-instance>/<org>/<repo>.git to obtain a local copy.
4. Craft a malicious push option: Construct a push option value containing the internal header delimiter character (semicolon) followed by injected metadata fields. For example: git push -o 'key=value;<injected-header-field>=<payload>'.
5. Execute the push: Run the crafted git push command against the vulnerable GHES instance. The babeld service processes the push options and includes the unsanitized value in an internal service header.
6. Trigger RCE: The injected header field overrides internal metadata, causing the server-side service to interpret and execute the attacker-controlled payload as a system command under the service account context.
7. Establish persistence: Use the initial RCE to deploy a reverse shell, web shell, or SSH key to maintain persistent access to the GHES instance for further lateral movement or data exfiltration (GitHub Blog, Wiz Research, undercodetesting.com).

• Network: Outbound connections from the GHES server to unexpected external IP addresses or domains, particularly following git push operations; unusual internal service-to-service traffic originating from the babeld process.
• Logs: Git push audit log entries containing push option values with semicolons or other delimiter characters in unexpected positions (e.g., git.push events in the GHES audit log with anomalous push_options fields); errors or anomalous entries in /var/log/github/babeld.log or internal header processing logs around the time of suspicious pushes.
• Process: Unexpected child processes spawned by the babeld or git proxy service (e.g., /bin/bash, curl, wget, python, nc) visible in process trees; unusual processes running under the git service account.
• File System: New or modified files in GHES service directories, unexpected cron jobs or systemd units, SSH authorized_keys modifications for service accounts, or web shells placed in accessible directories.
• Repository Activity: Push events from accounts that do not normally push to a repository, especially with unusual push option parameters; pushes occurring at unusual hours from unexpected IP addresses (GitHub Blog, Wiz Research).

GitHub has released patched versions addressing CVE-2026-3854: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, and 3.19.4 (note: the initial patch releases 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, and 3.19.3 were unpublished due to a separate Git version mismatch issue and superseded by the above versions). Administrators should upgrade immediately to the latest available patch for their release series. As an interim measure, restrict push access to repositories to only trusted and necessary users, and monitor git push audit logs for anomalous push option values. No configuration-based workaround that fully mitigates the vulnerability without patching has been published (GitHub Release Notes 3.14, GitHub Release Notes 3.15, GitHub Release Notes 3.16, GitHub Release Notes 3.17, GitHub Release Notes 3.18).

GitHub published a detailed security blog post titled "Securing the Git Push Pipeline" describing how Wiz Research discovered the vulnerability using AI-assisted analysis (Claude) and how GitHub patched it within approximately 6 hours of receiving the report — a response time highlighted positively by the community (GitHub Blog). Wiz Research published a comprehensive technical breakdown of the vulnerability and exploitation mechanics (Wiz Research). The vulnerability received widespread coverage from BleepingComputer, The Hacker News, SecurityWeek, The Register, CSO Online, and Help Net Security, with The Register noting the AI-assisted bug report was "genuinely helpful" rather than "total slop." Community discussion on Hacker News, Reddit (r/cybersecurity, r/programming, r/SecOpsDaily), and Mastodon was extensive, with many developers expressing concern about the low privilege bar required for exploitation. Security researcher Kevin Beaumont (@GossiTheDog) and others on Mastodon highlighted the severity and the risk to enterprise development environments. The statistic that ~88% of on-premise GHES instances remained unpatched at disclosure generated significant alarm in the security community (BleepingComputer, The Register, SecurityWeek).