command injection issue. An attacker with push access to a repository could exploit how GitHub handled user-supplied push options. These values were not properly sanitized before being passed into internal headers.
GitHub said the issue was related to how metadata was processed internally. The system used a delimiter format that could also appear in user input. This made it possible to inject additional fields and manipulate how the backend handled the request.
The vulnerability was discovered by Wiz and reported on March 4, 2026. GitHub validated the issue and pushed a fix to GitHub.com within two hours. That response time is fast, especially for a bug with this level of impact.
The more concerning part is how easy this was to exploit. Researchers showed that by chaining a few crafted inputs, an attacker could break out of the expected execution environment. This included bypassing sandbox protections that are meant to limit what Git hooks can do.
Once the sandbox is bypassed, the attacker could execute arbitrary commands on the server as the git user. An attacker can access internal configuration or read and write files.
On GitHub Enterprise Server, the impact was even more direct. Researchers were able to control hook execution paths and run unsandboxed code. On GitHub.com, similar results were possible by injecting internal flags through the same mechanism.
Because of GitHub’s shared infrastructure, this opened the door to cross-tenant exposure. In simple terms, a successful exploit could have allowed access to data belonging to other users or organizations on the same backend system.
Wiz noted that around 88 percent of instances were vulnerable at the time of disclosure. That number is high and shows how widespread the risk was before the patch.
GitHub has fixed the issue across its services. Enterprise Server users need to update to patched versions such as 3.14.25, 3.15.20, 3.16.16, and later releases. The company also said there is no evidence of active exploitation.
This incident is a classic example of trust boundaries breaking inside internal systems. The input came from an authenticated user, so it was treated as safe. But once that input crossed services without strict validation, it became an attack vector.
This issue points to a bigger gap in how modern systems are built. When different services pass data between each other using shared formats, even a small mistake can open the door to serious problems. Internal protocols often do not get checked as strictly as public APIs, and that is where things usually go wrong.
It also shows that even a simple git push can become an attack path if input is not handled properly. For developers and platform teams, this is a reminder to treat every bit of user input as untrusted, even when it is moving inside internal systems.
