How GitHub patched a critical code execution flaw in git push

GitHub’s security team recently neutralized a critical remote code execution vulnerability that could have allowed attackers to execute arbitrary commands during git push operations. The flaw, reported by researchers at Wiz through GitHub’s Bug Bounty program, was resolved in under two hours after validation, with no evidence of exploitation detected.

GitHub confirmed the issue stemmed from how user-supplied git push options were processed in the internal metadata pipeline. The company has outlined the timeline, remediation steps, and recommendations for affected users in a detailed post-mortem.

The initial report and rapid validation

On March 4, 2026, GitHub’s security team received a vulnerability report describing a method for authenticated users with push access to execute arbitrary commands on GitHub’s servers during push operations. The attack required only a single crafted git push command with a specially formatted push option, bypassing existing protections.

The security team prioritized the report and replicated the vulnerability internally within 40 minutes of receipt. The severity was assessed as critical, prompting an immediate response. By 7:00 p.m. UTC the same day, a patch had been developed and deployed to github.com, with a forensic investigation launched to determine if the flaw had been exploited prior to disclosure.

The technical flaw: How push options enabled code execution

GitHub’s infrastructure processes git push operations through multiple internal services. User-supplied push options—intended as a feature to pass metadata during pushes—were incorporated into internal protocol fields without proper sanitization. This oversight created an opportunity for injection attacks.

The vulnerability exploited a delimiter character in the internal metadata format that could also appear in user-provided values. By injecting additional fields into the metadata, an attacker could manipulate the environment in which the push operation was processed. This manipulation bypassed sandboxing protections, allowing arbitrary command execution on the server. The Wiz researchers demonstrated the attack chain required chaining multiple injected values to override default behavior.

git push origin main --push-option="key=value;injected_field=malicious_value"

The simplicity of the attack vector underscored the urgency of the response. Push options are a legitimate Git feature, but improper handling of their values in server-side processing introduced a significant risk.

Zero exploitation detected, but thorough investigation followed

With the fix deployed, GitHub’s primary concern was whether the vulnerability had been exploited before the report. A unique characteristic of the flaw provided critical insight: the exploit triggered a code path that is never used during normal GitHub operations. This path was logged, and telemetry analysis revealed that all occurrences corresponded to the Wiz researchers’ testing activity.

Key findings from the investigation included:

• No other users or accounts triggered the anomalous code path.
• No customer data was accessed, modified, or exfiltrated as a result of the vulnerability.
• For GitHub Enterprise Server (GHES) instances, exploitation would require an authenticated user with push access on the affected system.

GitHub recommended GHES users review their /var/log/github-audit.log for push operations containing semicolons in push options as a precaution.

Strengthening defenses beyond the immediate fix

While the primary remediation involved sanitizing user-supplied push option values, an additional hardening opportunity emerged during the investigation. The exploit succeeded in part because an unnecessary code path—intended only for specific product configurations—remained accessible in the server’s container image.

GitHub traced this lingering code path to a legacy deployment method that had been phased out but whose exclusions were not fully carried over during a migration. Removing this redundant path added another layer of defense, reinforcing the principle of defense in depth. Even if a similar injection flaw were to arise in the future, this hardening would limit the potential impact.

What action should users take now?

GitHub Enterprise Cloud, including variants with Enterprise Managed Users and Data Residency, as well as github.com, were patched on March 4, 2026. Users of these services do not need to take any further action.

For GitHub Enterprise Server (GHES) users, the risk is limited to instances where an authenticated user with push access could attempt exploitation. The company has released patched versions across all supported GHES releases, with specific update targets as follows:

• GitHub Enterprise Server 3.14.25 or later
• GitHub Enterprise Server 3.15.20 or later
• GitHub Enterprise Server 3.16.16 or later
• GitHub Enterprise Server 3.17.13 or later
• GitHub Enterprise Server 3.18.7 or later
• GitHub Enterprise Server 3.19.4 or later

GitHub strongly advises all GHES administrators to upgrade to the latest patched release immediately to mitigate any residual risk. The company also encourages logging reviews to confirm no unauthorized push operations occurred during the vulnerability window.

GitHub’s swift response to this critical flaw highlights the importance of coordinated vulnerability disclosure and rapid patching. As the Git ecosystem continues to evolve, such incidents serve as a reminder to maintain robust input validation and architectural isolation in critical infrastructure.