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 articleCircular dependencies can paralyze recovery during outages. By using eBPF and cGroups, engineers can enforce network isolation for deployment scripts without impacting production traffic, ensuring that critical infrastructure remains deployable even when primary services are offline.
CI/CD pipelines are prime targets for supply chain attacks. GitHub's roadmap moves to secure-by-design infrastructure, providing engineers with deterministic dependencies, granular policy controls, and real-time observability to protect sensitive code and credentials.
This bridges security gaps in infrastructure-as-code and scripts that traditional static analysis misses. By integrating AI-driven detections and automated fixes into the PR workflow, engineers can resolve vulnerabilities faster and maintain high security standards without leaving their tools.
This report highlights how complex dependencies—like telemetry, caching, and security policies—can trigger cascading failures. It provides valuable lessons on the importance of robust monitoring, automated rollbacks, and the need for resilient proxy layers in large-scale distributed systems.
