Run a single git push command, and get access to millions of repositories on GitHub. This is the critical massive remote code execution flaw uncovered by Wiz security researchers in a nutshell. They warn that 88% of GitHub Enterprise Servers remain unpatched.

GitHub has patched a fundamental flaw that enabled any user to inject malicious code into the git push command, compromise GitHub’s infrastructure, and gain read and write access to millions of impacted repositories.

“Millions of public and private repositories belonging to other users and organizations were accessible on the affected nodes. On GitHub Enterprise Server, the same vulnerability grants full server compromise, including access to all hosted repositories and internal secrets,” Wiz said in a report about one of the most serious vulnerabilities ever affecting GitHub.

GitHub is the world’s largest platform for storing and sharing software code used by the majority of developers and companies globally. Git push is a routine command any developer would use to upload their code changes – it's like clicking the “save” button.

While GitHub deployed a fix to github.com back on March 4th, 2026, Wiz estimates that 88% of GitHub Enterprise Server instances remain vulnerable. Exploiting the flaw requires an authenticated user with push access.

GitHub’s security advisory urges administrators to upgrade their instances to the latest patch release as soon as possible.

How does the exploit work?

The attack only requires a single git push command with a crafted push option that leverages an unsanitized character – a semicolon (“;”).

The semicolon is a separator that tells the system where one system ends and the next begins. The GitHub internal services used it to pass metadata, such as repository time, environment, and security settings, without proper sanitization.

“Push options are an intentional feature of git that allow clients to send key-value strings to the server during a push,” GitHub explains.

An attacker could use semicolons to chain and inject additional fields that the downstream GitHub services would interpret as trusted internal values.

“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,” GitHub acknowledged.

Wiz researchers said that any semicolon in a git push option value breaks out of its designated field and creates new, attacker-controlled fields.

“If a key appears twice, the later value silently overrides the earlier one,” the researchers said.

Attackers could tamper with GitHub’s custom headers so that their values would replace legitimate counterparts.

Wiz found three fields, which, when tampered with, allowed an attacker to escape the sandbox, redirect the hook, the mechanism that loads and runs script, to any directory on the server, and ultimately trick the GitHub system into executing any program on the machine.

“The non-production path then executes the resolved path directly – no arguments, no sandbox – as the git service user,” the report reads.

For a GitHub-wide exploit, the attacker would also need to add one more flag that switches the system into enterprise mode.

The potential consequences could’ve been devastating – attackers could’ve compromised millions of GitHub repositories.

“We did not access the contents of other tenants’ repositories. We validated the cross-tenant exposure using only our own test accounts, confirming that the git user’s filesystem permissions would allow reading any repository on the node,” the researchers assured.

GitHub patched the flaw in hours

The vulnerability was discovered using AI-augmented reverse engineering – the task, given GitHub’s complexity, was previously too costly and time-consuming to be practical.

Wiz responsibly disclosed the vulnerability to GitHub via a Bug Bounty program on March 4th. GitHub acknowledged the flaw and deployed the fix in hours.

Have thoughts about this topic? Others do, too. Join them in the discussion.

“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,” GitHub assures.

“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.”

Unlock more exclusive Cybernews content on YouTube.