GitHub yesterday disclosed CVE-2026-3854, a high severity (8.7 CVSS) vulnerability identified in GitHub Enterprise Server that would grant an attacker with push access to a repository to achieve remote code execution. GitHub said in a blog post that the vulnerability also affected github.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud with Data Residency, and GitHub Enterprise Cloud with Enterprise Managed Users.
Cloud security firm Wiz reported the vulnerability March 4 through GitHub’s bug bounty program. GitHub said that, in less than two hours, it validated the finding, pushed a fix to github.com, and, after an investigation, concluded no exploitation had taken place.
While a remote code execution bug generally is worth calling attention to, the circumstances here are particularly noteworthy, as Wiz explained in its blog post. It’s “one of the first critical vulnerabilities discovered in closed-source binaries using AI, highlighting a shift in how these flaws are identified.”
How CVE-2026-3854 Works
As GitHub’s Alexis Wales put it in the company’s disclosure blog, user-pushed code in GitHub passes multiple internal services. Metadata, such as repository type and the environment it should be pushed in, is passed between services via 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,” she wrote. “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.”
Wiz demonstrated that an attacker could chain several of these values together to bypass various protections and internal limitations to execute remote code.
GitHub and Wiz both advise GitHub Enterprise Server customers to upgrade to a fixed version (3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6 and 3.19.3); contrary to other affected products, Enterprise Server requires an authenticated user with push access to patch. GitHub Enterprise Cloud, GitHub Enterprise Cloud with Enterprise Managed Users, GitHub Enterprise Cloud with Data Residency, and github.com have been patched, and no user intervention is required.
In Wiz’s blog post, security researcher Sagi Tzadik urged impacted users to upgrade, noting 88% of instances remained vulnerable at the time of publication.
AI Reverse-Engineered Vulnerability Discovery
Tzadik wrote that Wiz had previously hunted for vulnerabilities on GitHub Enterprise Server, but “extracting and auditing the sheer volume of compiled blackbox binaries that run this pipeline historically required an impractical amount of time and manual effort.”
Enter IDA MCP, an AI-powered assistant used for vibe reverse-engineering code. It allowed Wiz to do what was previously “too costly,” the blog explained, such as rapidly analyzing GitHub’s compiled binaries, reconstructing internal protocols, and systematically identifying where user input could influence server behavior.
In an email, Tzadik tells Dark Reading that Wiz has been “chasing this target since September 2024,” but couldn’t justify the resources required to do the reverse-engineering work. “It likely would have taken weeks, maybe months, of dedicated time and focus. With the help of AI tools, it took less than 48 hours to go from idea to a working exploit,” he says.
The closed source element of GitHub is also important, the researcher says, because closed source software historically has been home to the biggest security risks and the most obscurity. “As the latest AI models have improved, it’s become much easier, faster, and cheaper to do things like reverse-engineer closed-source binaries, or produce a working exploit from a CVE identifier and a git commit hash as input,” Tzadik explains. “Scale is also a factor — while researchers used to work on a limited set of projects at a given time, these days it is possible to run automated pipelines on multiple targets at once.”
