"A single git push command was enough to exploit a flaw in GitHub's internal protocol and achieve code execution on backend infrastructure," Wiz said.
CVE-2026-3854: the injection chain
Researchers have assigned CVE-2026-3854 to a command-injection defect in GitHub's internal handling of user-supplied git push options. The vulnerability carries a CVSS score of 8.7. At its technical core, push option values were not properly sanitized before being included in an internal X-Stat header. That header format uses a semicolon as a delimiter; because semicolons can appear inside user input, crafted push options could inject additional metadata fields and alter service behavior.
The exploit sequence demonstrated by Wiz strings together three specific injections. First, an attacker injects a non-production rails_env value to bypass sandboxing. Second, they overwrite custom_hooks_dir to redirect the hook directory. Third, they set repo_pre_receive_hooks to a crafted hook entry that uses path traversal to run arbitrary commands as the git user. Chaining these three changes allows an attacker to escape sandbox protections and execute arbitrary commands on the server.
How Wiz found the flaw and GitHub's rapid mitigation
Google-owned cloud security firm Wiz discovered and reported the issue on March 4, 2026. GitHub validated the report and deployed a fix to GitHub.com within two hours of notification. Wiz described the vulnerability as "remarkably easy" to exploit, and its public write-up emphasized how assumptions made by different services about shared data formats create critical attack surfaces.
Wiz security researcher Sagi Tzadik summarized the consequences: "With unsandboxed code execution as the git user, we had full control over the GHES instance, including filesystem read/write access and visibility into internal service configuration." GitHub's Chief Information Security Officer, Alexis Wales, explained that the sanitation failure allowed attackers to inject metadata fields and override the environment in which pushes were processed, bypassing normal hook sandboxing protections and enabling remote code execution.
Products, versions, and the scope of remediation
GitHub reports the issue affected GitHub.com, GitHub Enterprise Cloud (including variants with Data Residency and Enterprise Managed Users), and GitHub Enterprise Server (GHES). For GHES, the security advisory lists patched versions: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, and 3.20.0 or later. GitHub said there is no evidence the issue was ever exploited in a malicious context.
At the time of public disclosure, Wiz reported that about 88% of instances were vulnerable. GitHub has advised users to apply the update immediately for optimal protection.
Risk to GitHub.com’s multi-tenant architecture and shared storage
The advisory highlights a particular danger tied to GitHub's multi-tenant, shared-backend design. On GitHub.com, an enterprise mode flag—set to "true" for enterprise server deployments and defaulting to "false" on GitHub.com—normally keeps custom hooks inactive. That flag itself is passed in the injectable X-Stat header, however, and therefore could be modified by the same push-option injection. In other words, the same mechanism that compromises GHES could be used to flip behavior on GitHub.com and trigger code execution.
Because of shared storage nodes, obtaining code execution on GitHub.com could expose repositories beyond the attacker’s nominal tenant. GitHub warned that code execution on shared storage nodes could allow an attacker to read millions of repositories on that node, regardless of organization or user boundaries.
What this means for security teams, enterprise users, and end users
- Security teams: Prioritize patching GHES instances to one of the listed patched versions and verify that GitHub.com mitigations were applied. Audit internal protocols where services rely on shared metadata formats and delimiter characters, and treat user-controlled input that flows through those protocols as a high-risk attack surface.
- Enterprise procurement and operations: Confirm your GHES release level matches a patched version (3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 or later) and validate any compensating controls for shared storage exposure during upgrade windows.
- End users and repository owners: Monitor communications from GitHub about applied fixes and follow guidance to rotate credentials or review access logs if your organization hosted repositories on potentially affected nodes; GitHub reported no evidence of malicious exploitation but advised immediate updating.
Wiz concluded its coordinated announcement with a pointed reminder: when multiple services written in different languages pass data through a shared internal protocol, the assumptions each service makes about that data become a critical attack surface. That admonition is the actionable thread running through this episode: a single unsanitized header field, exploited with a single git push, was enough to expose backend infrastructure across shared environments. For organizations that depend on shared services and internal protocols, the near-term step is clear—apply the fixes listed and audit how user-controlled input is propagated internally. The longer-term question is whether similar delimiter- and header-based assumptions exist elsewhere in the stacks we all rely upon.
