This incident highlights how minor sanitization failures in internal protocols can lead to critical RCE. It underscores the importance of defense-in-depth, showing how removing unused code paths and robust telemetry can mitigate risks and verify the absence of exploitation.
On March 4, 2026, we received a vulnerability report through our Bug Bounty program from researchers at Wiz describing a critical remote code execution vulnerability affecting github.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, GitHub Enterprise Cloud with Enterprise Managed Users, and GitHub Enterprise Server.
In less than two hours we had validated the finding, deployed a fix to github.com, and begun a forensic investigation that concluded there was no exploitation.
In this post, we want to share what happened, how we responded, and what we are doing to prevent similar issues in the future.
The bug bounty report described a way for any user with push access to a repository, including a repository they created themselves, to achieve arbitrary command execution on the GitHub server handling their git push operation. The attack required only a single command: git push with a crafted push option that leveraged an unsanitized character.
Our security team immediately began validating the bug bounty report. Within 40 minutes, we had reproduced the vulnerability internally and confirmed the severity. This was a critical issue that required immediate action.
When a user pushes code to GitHub, the operation passes through multiple internal services. As part of this process, metadata about the push, such as the repository type and the environment it should be processed in, is passed between services using an internal protocol.
The vulnerability leveraged how user-supplied git push options were handled within this metadata. Push options are an intentional feature of git that allow clients to send key-value strings to the server during a push. However, the values provided by the user were incorporated into the internal metadata without sufficient sanitization. Because the internal metadata format used a delimiter character that could also appear in user input, an attacker could inject additional fields that the downstream service would interpret as trusted internal values.
By chaining several injected values together, the researchers demonstrated that an attacker could override the environment the push was processed in, bypass sandboxing protections that normally constrain hook execution, and ultimately execute arbitrary commands on the server.
With the root cause identified on March, 4, 2026, at 5:45 p.m. UTC, our engineering team developed and deployed a fix to github.com at 7:00 p.m. UTC that same day. The fix ensures that user-supplied push option values are properly sanitized and can no longer influence internal metadata fields.
For GitHub Enterprise Server, we prepared patches across all supported 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 published CVE-2026-3854. These are available today and we strongly recommend that all GHES customers upgrade immediately.
With the immediate fix in place on github.com, we moved to the pressing question of whether anyone else found and exploited this vulnerability before the researchers reported it.
A key property of this vulnerability gave us confidence in our ability to answer that question. The exploit forces the server to take a code path that is never used during normal operations on github.com. This is not something an attacker can avoid or suppress, as it is an inherent consequence of how the injection works.
We logged this path and queried our telemetry for any instance of this anomalous code path being executed. The results were clear:
For GHES customers, exploitation would require an authenticated user with push access on your instance. We recommend reviewing your access logs out of an abundance of caution.
Beyond fixing the immediate input sanitization issue, our investigation surfaced an additional finding worth sharing.
The exploit worked in part because the server had access to a code path that was not intended for the environment it was running in. This code path existed on disk as part of the server’s container image, even though it was only meant to be used in a different product configuration. An older deployment method had correctly excluded this code, but when the deployment model changed, the exclusion was not carried forward.
This is a useful reminder that defense in depth matters. The input sanitization fix is the primary remediation, but we have also removed the unnecessary code path from environments where it should not exist. Even if a similar injection vulnerability were discovered in the future, this additional hardening would limit what an attacker could do with it.
GitHub Enterprise Cloud, GitHub Enterprise Cloud with Enterprise Managed Users, GitHub Enterprise Cloud with Data Residency, and github.com were patched on March 4, 2026. No action is required from users of any of these.
As mentioned previously, exploitation on GitHub Enterprise Server requires an authenticated user with push access on your instance. We recommend that you review /var/log/github-audit.log for push operations containing ; in push options. Updates are available in the following releases:
We strongly recommend upgrading to the latest patch release as soon as possible. See the GHES release notes for details.
This vulnerability has been assigned CVE-2026-3854.
This vulnerability was discovered and responsibly disclosed by researchers at Wiz. Their report was thorough, clearly demonstrated the impact, and enabled us to move quickly from validation to remediation. This finding will receive one of the highest rewards in the history of our Bug Bounty program, which has been a cornerstone of our security program for over a decade.
The post Securing the git push pipeline: Responding to a critical remote code execution vulnerability appeared first on The GitHub Blog.
Continue reading on the original blog to support the author
Read full articleManaging dependency updates is a critical but time-consuming maintenance task. Automating the initial triage with AI reduces cognitive load, ensures security patches aren't missed, and lets engineers focus on breaking changes rather than routine version bumps.
Moving LLMs to production requires more than high benchmark scores. This framework ensures reliability by balancing user benefits against security risks and operational costs, preventing regressions in complex AI-driven workflows.
GitHub agent apps minimize context switching by integrating analytics, security, and deployment tools into the PR workflow. This enables engineers to make data-driven decisions and manage rollouts without leaving GitHub, significantly improving developer velocity and system safety.
Excessive Dependabot noise leads to notification fatigue and wasted CI resources. Grouping updates and adjusting cadence optimizes developer productivity and reduces costs without compromising security, as critical vulnerability patches bypass these scheduled batching rules.
