GitHub Fixed Critical RCE Vulnerability in Under Six Hours

Key Takeaways

• GitHub patched a critical remote code execution vulnerability in under six hours after Wiz Research reported it
• This is one of the first critical vulnerabilities in closed-source binaries discovered using AI
• The flaw was 'remarkably easy to exploit' and could have exposed millions of public and private repositories

GitHub employees fixed a critical remote code execution vulnerability in less than six hours last month. The flaw, discovered by Wiz Research using AI, could have allowed attackers to access millions of public and private code repositories through GitHub's internal git infrastructure.

The rapid response marks a notable win for GitHub's security team. It also signals a shift in how critical vulnerabilities are found. Wiz says this is one of the first major flaws in closed-source binaries discovered with AI assistance.

40 Minutes to Validate, Two Hours to Fix

Alexis Wales, GitHub's chief information security officer, outlined the timeline. The security team reproduced the vulnerability internally within 40 minutes of receiving Wiz's bug bounty report. They confirmed the severity immediately.

“This was a critical issue that required immediate action.”

— Alexis Wales, GitHub CISO

GitHub's engineering team developed and deployed a fix just over an hour after identifying the root cause. The patch protected both GitHub.com and GitHub Enterprise Server.

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

— Alexis Wales, GitHub CISO

The entire process, from initial report to deployed fix, took under six hours.

AI Found the Flaw

Wiz Research discovered the vulnerability "using AI," though the company did not specify which model. Sagi Tzadik, a Wiz security researcher, emphasized the significance of the discovery method.

"Notably, this is one of the first critical vulnerabilities discovered in closed-source binaries using AI, highlighting a shift in how these flaws are identified," Tzadik said.

This approach suggests AI tools are becoming practical for security research beyond open-source code analysis. Closed-source binaries are harder to examine because researchers cannot read the underlying source code directly.

Easy to Exploit, Hard to Find

Despite GitHub's complex underlying system, Wiz warns the vulnerability was "remarkably easy to exploit." This combination, easy exploitation with difficult discovery, makes such flaws particularly dangerous.

Wales acknowledged the severity earned one of the highest rewards in GitHub's bug bounty program. "A finding of this caliber and severity is rare," she said. It "serves as a reminder that the most impactful security research comes from skilled researchers who know how to ask the right questions."

Timing Matters

The vulnerability disclosure comes during a rough stretch for GitHub reliability. Days before this report, GitHub experienced a major outage that randomly reverted previously merged commits for some users. Additional outages hit the platform last week.

Reports have surfaced about employee concerns over GitHub's stability. One GitHub employee reportedly said "the company is collapsing, both in outages that are reallllly bad and have torched the company reputation... and in an exodus of leadership."

The quick security response stands in contrast to these reliability issues. GitHub's ability to validate and patch a critical vulnerability in hours shows the security team can still move fast when needed.

Frequently Asked Questions

What was the GitHub vulnerability?

A critical remote code execution flaw in GitHub's internal git infrastructure. It could have allowed attackers to access millions of public and private repositories.

How was the GitHub vulnerability discovered?

Wiz Research found it using AI. This is one of the first critical vulnerabilities in closed-source binaries discovered with AI assistance.

Was the GitHub vulnerability exploited?

No. GitHub's forensic investigation concluded there was no exploitation before the patch was deployed.

How quickly did GitHub fix the vulnerability?

Under six hours from initial report to deployed fix. The security team validated the issue in 40 minutes and deployed a patch in under two hours after that.

Does this affect GitHub Enterprise Server?

The fix protected both GitHub.com and GitHub Enterprise Server, according to GitHub's CISO.