
Discovered by Wiz researchers through AI-augmented reverse engineering of closed-source compiled binaries, CVE-2026-3854 stems from an improper neutralization of special elements (CWE-77) in how GitHub’s internal babeld git proxy handled user-supplied push option values.
When a user executes git push -o, arbitrary option strings are passed to the server. The vulnerability arises because babeld copied these values verbatim into a semicolon-delimited internal X-Stat header without sanitizing the semicolon character the same character used as a field delimiter.
Because the downstream service gitrpcd parsed the X-Stat header using last-write-wins semantics, an attacker could inject new key-value fields simply by embedding a semicolon followed by a field name and value inside a push option.
Security-critical fields including rails_env, custom_hooks_dir, and repo_pre_receive_hooks were all overridable through this single injection vector.
The escalation to RCE required chaining three injected fields together:
-
Bypass the sandbox — Injecting a non-production
rails_envvalue switched the pre-receive hook binary from its sandboxed execution path to an unsandboxed, direct-execution path -
Redirect the hook directory — Overriding
custom_hooks_dirredirected where the binary searched for hook scripts -
Path traversal to arbitrary execution — Injecting a crafted
repo_pre_receive_hooksentry with a path traversal payload caused the binary to resolve and directly execute an arbitrary filesystem binary as thegitservice user
The entire exploit required no privilege escalation, no special tooling, and no zero-day dependencies — just a standard git client.
On GitHub Enterprise Server, exploitation granted full server compromise, including read/write access to all hosted repositories and internal secrets.
On GitHub.com, Wiz initially found that the custom hooks code path was inactive by default, but discovered a boolean enterprise_mode flag in the X-Stat header was equally injectable, enabling the full chain on GitHub.com’s shared infrastructure as well.
Upon achieving RCE on GitHub.com’s shared storage nodes, Wiz confirmed that the git The service user had filesystem access to millions of repositories belonging to other users and organizations on those nodes.
The Wiz researchers did not access third-party content, using only their own test accounts to validate the cross-tenant exposure.
Notably, this marks one of the first critical vulnerabilities in closed-source binaries to be uncovered using AI tooling at scale.
Wiz leveraged IDA MCP for automated reverse engineering, enabling rapid reconstruction of GitHub’s internal protocols across compiled binaries, an analysis that would have been prohibitively time-consuming manually.
This signals a meaningful shift in the methodology for vulnerability research in opaque, multi-service architectures.
GitHub received the report on March 4, 2026, validated it within hours, and deployed a fix to GitHub.com by 7:00 p.m. UTC the same day, roughly within the 6-hour response window. GitHub’s forensic investigation confirmed no exploitation occurred prior to disclosure.
For GitHub Enterprise Server, patches are available, and GHES administrators must act immediately:
| Component | Vulnerable Versions | Fixed Version |
|---|---|---|
| GitHub Enterprise Server | ≤ 3.19.1 | 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4+ |
At the time of disclosure, Wiz data indicated 88% of GHES instances remained unpatched. GitHub Enterprise Cloud and GitHub.com users require no action.
GHES administrators should also audit /var/log/github-audit.log for push operations containing unusual special characters in push option values as indicators of prior exploitation attempts.
Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.
The post Critical GitHub.com and Enterprise Server RCE Vulnerability Enables Full Server Compromise appeared first on Cyber Security News.
Discover more from RSS Feeds Cloud
Subscribe to get the latest posts sent to your email.
