GitHub patched critical RCE after AI-assisted vulnerability research

GitHub has disclosed a critical RCE vulnerability in its git push pipeline.

Fact: GitHub wrote on April 28, 2026 that it received a bug bounty report from Wiz on March 4 covering CVE-2026-3854. The flaw sat in GitHub's internal git infrastructure and could allow arbitrary command execution on the server processing a git push operation. According to GitHub, the issue affected GitHub.com, GitHub Enterprise Cloud, Enterprise Cloud with Data Residency, Enterprise Managed Users and GitHub Enterprise Server.

GitHub says its security team reproduced the report within 40 minutes. Once the root cause had been identified at 17:45 UTC, GitHub developed and deployed a fix for GitHub.com at 19:00 the same day. The company also says its forensic investigation found no exploitation outside Wiz's own testing, and no customer data was accessed, modified or exfiltrated as a result of the vulnerability.

Wiz describes the issue in sharper terms: an authenticated user could exploit weak sanitisation of git push options, override internal metadata and bypass sandboxing controls. Wiz also says AI was used in the research that found the bug in closed-source binaries. That does not make AI magic, but it changes the economics of vulnerability discovery. More teams can inspect complex systems faster than before.

The leadership consequence is practical. GitHub is not just a developer tool. In many companies it is the control plane for source code, CI/CD, secrets, pull requests and supplier access. When a critical flaw hits that surface, the question is not only whether GitHub responded quickly. The question is whether your own organisation knows which GitHub Enterprise Server instances exist, what versions they run, who has push access, and how fast an emergency patch can actually be deployed.

GitHub.com customers do not need to act on the platform fix, according to GitHub. GitHub Enterprise Server customers must upgrade to patched supported releases. GitHub lists versions including 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 or later. This should be treated as a security and operations priority, not ordinary backlog.

Assessment: The most important lesson is response capability. GitHub demonstrated strong incident response, with validation, patching and forensics measured in hours. At the same time, the case shows that closed internal control planes are not insulated from AI-assisted security analysis. That raises the bar for asset inventory, patch SLAs, logging and supplier governance.

Advice for CIOs and CISOs: Check GHES versions today. Confirm that push access is tightly limited. Review whether your own logging and access-log review match GitHub's guidance. Bring the case into your next vendor governance meeting as well: How fast do critical security notices reach you, who owns the decision, and is there a tested emergency process for the developer platform?

Sources: GitHub Security Blog, April 28, 2026: https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/. Wiz Research, April 28, 2026: https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854.