CVE-2026-3854 could have let an attacker unlock “millions of public and private repositories” with a single malicious git push, researchers warned after reporting the flaw in early March.
How the flaw worked: user-supplied git push options became trusted metadata
The vulnerability stemmed from how GitHub handled user-supplied options during git push operations. Values provided by a user were incorporated into internal server metadata without sufficient sanitization, enabling an attacker to inject additional fields that downstream services trusted. As GitHub Chief Information Security Officer Alexis Wales described, the injected values could be chained so that an attacker “could bypass sandboxing protections and execute arbitrary code on the server handling the push.” Successful exploitation required only a single maliciously crafted 'git push' command and an attacker with push access.
Products affected and the technical impact
CVE-2026-3854 affected multiple GitHub offerings: GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, GitHub Enterprise Cloud with Enterprise Managed Users, and GitHub Enterprise Server. Wiz security researcher Sagi Tzadik summarized the worst-case outcomes: “On GitHub.com, this vulnerability allowed remote code execution on shared storage nodes. We confirmed that millions of public and private repositories belonging to other users and organizations were accessible on the affected nodes.” For GitHub Enterprise Server, Tzadik warned the vulnerability “grants full server compromise, including access to all hosted repositories and internal secrets.”
Timeline: disclosure, confirmation, and rapid patching
Wiz reported the issue to GitHub on March 4, 2026, through GitHub's bug bounty program. According to Wales, GitHub’s security team reproduced and confirmed the vulnerability “within 40 minutes and deployed a fix to GitHub.com less than two hours after receiving the report.” Wiz’s public commentary noted that GitHub had patched the issue on GitHub.com “within 6 hours,” a close but separately reported timeframe. For GitHub Enterprise Server (GHES), GitHub prepared and published patches across supported releases and published CVE-2026-3854.
Investigation results: no evidence of prior exploitation on GitHub.com
Following the disclosure and remediation on GitHub.com, a forensic investigation turned up no evidence that the vulnerability had been exploited before Wiz’s report. GitHub said telemetry data confirmed every instance of the anomalous code path was attributable solely to the Wiz researchers' testing. Wales stated that “no other users or accounts triggered the code path used to exploit this vulnerability, and that no customer data was accessed, modified, or exfiltrated as a result of CVE-2026-3854 exploitation before patches were deployed on GitHub.com.”
Patches, remaining risk, and what administrators should do
GitHub produced patches for GitHub Enterprise Server across its supported releases—listed by release numbers—and urged customers to upgrade immediately. Wales detailed the rollouts for GHES releases 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0, “or later,” and said those fixes were available at publication. Wiz additionally cautioned that roughly 88% of reachable GHES instances remained vulnerable, and its researcher advised that GHES administrators should upgrade without delay.
What this means for GHES administrators, enterprises, and open-source projects
- GHES administrators: Install the published patches for your supported release immediately; the vulnerability can result in full server compromise on GHES and was specifically called out as granting access to “all hosted repositories and internal secrets.”
- Enterprises and organizations with code on GitHub.com: Review telemetry and push-access controls; on GitHub.com the immediate incident response and telemetry review found no customer-data exposure, but the scale of the potential impact—“millions of public and private repositories” accessible on affected nodes—means organizations should verify their own logs and access lists.
- Open-source maintainers and projects: Audit who holds push access to critical repositories and consider tighter controls on credentials and deploy workflows that limit what a single push can affect, given the exploit requirement of a malicious push command by an account with push privileges.
The disclosure underscores how a single, subtle failure to sanitize user-provided options can cascade into broad, high-severity outcomes across both hosted and self-hosted platforms. GitHub’s rapid in-house reproduction and remediation on GitHub.com, paired with Wiz’s public reporting, closed the immediate risk on the hosted service; the remaining frontier now is upgrading and validating GHES instances worldwide. As GitHub and third-party researchers continue to monitor and patch, the practical question left for many organizations is straightforward and urgent: have you updated your GHES nodes to one of the fixed releases?
Source: BleepingComputer — GitHub fixes RCE flaw that gave access to millions of private repos
