GitHub.com & GitHub Enterprise Server Pre-Auth RCE via X-Stat Header Field Injection (CVE-2026-3854) — Threadlinqs Intelligence
As of 2026-05-30, GitHub.com & GitHub Enterprise Server Pre-Auth RCE via X-Stat Header Field Injection (CVE-2026-3854) is a high-severity vulnerability threat, tracked by Threadlinqs Intelligence with 9 detection rules (Splunk SPL, Microsoft KQL, Sigma) and 21 indicators of compromise.
Threat ID: TL-2026-0434 · Severity: HIGH · CVSS: 8.7 · Status: MONITORING · Category: VULNERABILITY
Wiz Research disclosed CVE-2026-3854 (CVSS 8.7) on 2026-04-28: an authenticated remote code execution flaw in GitHub.com and GitHub Enterprise Server. babeld embeds user-controlled git push option
CVE-2026-3854 is a critical injection vulnerability in GitHub's internal git infrastructure, disclosed publicly by Wiz Research (Sagi Tzadik et al.) on 2026-04-28. The flaw arises from inconsistent handling of a shared internal protocol — the X-Stat HTTP header — across multiple services in the git push pipeline (babeld, gitauth, gitrpcd, and the pre-receive hook binary). An authenticated user with push access to any repository can execute arbitrary commands on GitHub backend servers using nothing but a standard git client.
When a user runs `git push` over SSH, the request flows through several internal services. babeld (the git proxy) authenticates via gitauth, then constructs an internal X-Stat header containing security-critical metadata: file size limits, branch naming rules, hook execution mode, custom hook directory, and a JSON manifest of pre-receive hooks. The X-Stat header carries these fields as semicolon-delimited key=value pairs, parsed downstream into a map with last-write-wins semantics. babeld also encodes user-supplied git push options (`git push -o key=value`) as numbered fields (`push_option_0`, `push_option_1`, ..., `push_option_count`) and embeds them verbatim into the same header — without sanitizing semicolons.
Because `;` is the X-Stat field delimiter, any semicolon in a push option value escapes its designated field and creates new attacker-controlled fields. The downstream parser overwrites earlier (legitimate) values with later (injected) values, allowing the attacker to override security-critical fields including `rails_env` (controls whether hooks run inside the sandbox or directly), `custom_hooks_dir` (base directory for hook script lookup), `repo_pre_receive_hooks` (JSON definitions of pre-receive hooks), `large_blob_rejection_enabled`, `reject_sha_like_refs`, and `user_operator_mode`.
Wiz chained three injections to achieve RCE: (1) inject a non-production `rails_env` value to switch from the sandboxed hook execution path to the unsandboxed path that runs hooks directly as the git service user; (2) inject `custom_hooks_dir` to control the base directory where the binary looks up hook scripts; (3) inject a `repo_pre_receive_hooks` 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, which the non-production path then executes directly with no arguments and no sandbox. On GitHub.com one additional injected field (an enterprise-mode boolean defaulting to false on GitHub.com but true on GHES) was required to reach the custom-hooks code path; once flipped, the same chain executed `hostname` on GitHub.com infrastructure.
The impact differs by deployment. On GHES, exploitation grants full server compromise: code execution as the git user yields filesystem read/write, access to all hosted repositories, and visibility into internal service configuration and secrets. On GitHub.com — a multi-tenant platform — exploitation lands on a shared storage node where the git user has broad filesystem access to every repository hosted on that node. Wiz enumerated millions of repository index entries belonging to other organizations and users from two compromised nodes, validating cross-tenant exposure (without accessing any third-party repository contents).
The research was enabled by AI-augmented reverse engineering of GitHub's compiled, closed-source binaries (notably IDA MCP), making this one of the first critical vulnerabilities discovered in closed-source binaries using AI tooling. GitHub mitigated the issue on GitHub.com within 6 hours of Wiz's report, released patches across all supported GHES branches (3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, 3.19.3), and published the CVE on patch release. As of the disclosure blog (2026-04-28), Wiz's telemetry indicated 88% of internet-exposed GHES instances were still running vulnerable versions. No act
Weaknesses (CWE)
CWE-93, CWE-74, CWE-20, CWE-94, CWE-78, CWE-22, CWE-471
Target sectors: technology, software-development, financial, government, defense, healthcare, manufacturing, telecommunications, all-sectors-using-ghes
Target regions: Global, North America, Europe, Asia Pacific
Detections & IOCs
As of 2026-07-28, this threat has 9 detection rule(s) across Splunk SPL, Microsoft KQL and Sigma, and 21 indicator(s) of compromise. Detection query text and full IOC values are available to authenticated users and programmatically via the Threadlinqs MCP server (Purple tier). View plans.
VULNERABILITY, HIGH, threat intelligence, cybersecurity, CVE-2026-3854, T1190, T1078, T1199, T1059, T1059.004, T1203, T1505, T1505.003, T1546, T1068