GitHub Let a Git Push Hijack Its Servers

GitHub published two posts on April 28, 2026. One was the CTO apologizing for reliability. The other was a critical remote code execution vulnerability in the git push pipeline. Same morning, same platform. ^[1] [2]

TL;DR: Wiz found that a single git push with crafted options could run code on GitHub's servers, outside any sandbox (CVE-2026-3854, CVSS 8.7). Five days earlier, GitHub's merge queue silently reverted 2,092 pull requests. Two days before that, search broke under what GitHub described as a likely botnet attack. Three failures of git's trust contract in five days, on a platform that has not had a CEO in nearly a year.

What is CVE-2026-3854 and how did a git push hijack GitHub's servers?

A critical remote code execution vulnerability in GitHub's git push pipeline. Wiz researchers reported it on March 4, 2026. GitHub patched github.com 75 minutes later. Public disclosure held until April 28 to let GitHub Enterprise Server customers patch. ^[1] [2]

The exploit needed a standard git client and one command. No malware, no phishing, no privileged token. A push option with a semicolon was enough.

How did Wiz turn a single git push into a server takeover?

GitHub's git proxy, babeld, embeds user-supplied push option values into an internal X-Stat header that downstream services read to enforce policy. The values were not sanitized for the field delimiter, a semicolon. Last write wins. ^[2]

Three injections, in order:

• A non-production rails_env to bypass sandbox restrictions.
• An overridden custom_hooks_dir to redirect hook lookups.
• A repo_pre_receive_hooks value with path traversal, pointing the server at a binary the attacker controlled.

The result was unsandboxed code execution as the git service user. On GitHub.com, that user's permissions reach across tenants. Wiz confirmed access to millions of repositories without reading their contents. ^[2]

Why are 88% of GitHub Enterprise Server instances still vulnerable?

Because patches dropped on April 28, the same day as disclosure. Enterprise rollout is slow. Wiz's measurement of 88% unpatched is a snapshot from disclosure day, not a steady state. ^[2]

The fix is in GHES 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6, and 3.19.3. GitHub also recommends GHES customers grep /var/log/github-audit.log for push operations containing semicolons to check for prior exploitation attempts. ^[1]

Who loses: any organization that runs GHES, has not patched, and has a public-facing push surface. Who wins: Wiz, both for the finding and for the methodology. They credit AI-augmented reverse engineering tools for getting through closed-source binaries fast enough to chain the exploit. ^[2]

What happened to GitHub's merge queue on April 23?

The merge queue's squash path generated commits from the wrong base when a queue group contained multiple pull requests. Earlier merges in the group appeared to revert. GitHub's count: 2,092 pull requests across 658 repositories. ^[3] [4]

No data was lost. Every commit is still in Git storage. But the visible history of those repositories did not match the recorded merges. Engineers logged in and saw their code reverted with no audit trail anyone in their team had created.

Tom Elliott, who first publicized the bug, said it best: it "breaks the mental contract teams have with Git in general." ^[4]

Why did GitHub search break on April 27?

The Elasticsearch subsystem was overloaded, likely by a botnet. Search across PRs, issues, and projects stopped returning results. Git operations and APIs were unaffected. ^[3]

This is the most ordinary of the three. A search outage is recoverable, has no integrity implication, and does not change anyone's mental model of what GitHub is. It matters here only as the third entry in the same week.

Is GitHub having a reliability problem in 2026?

The CTO says yes, in different words. Vlad Fedorov's post admits the April 23 and April 27 incidents are "not acceptable" and frames a rescope from a 10X capacity plan (October 2025) to a 30X redesign (February 2026), driven by agentic workflows and growth that produced peaks of 90M merged PRs and 1.4B commits. ^[3]

Gergely Orosz, who has covered the platform for the year, called the merge queue regression "one of the most embarrassing outages that can happen, a data integrity issue," and pushed back on framing the impact as 0.07% of merges. ^[5] Mario Zechner, putting the engineer-on-the-ground view: "this is not a dependable platform anymore. every day something else is broken." ^[6]

Git is the boring layer. GitHub spent April making it interesting.

What does it mean that GitHub has not had a CEO in nearly a year?

GitHub's C-suite still has a CFO, COO, CTO, CPO, CRO, and Chief of Staff. The seat above them has been empty since mid-2025, after Thomas Dohmke's departure and Microsoft's decision to fold GitHub into a "core AI" organizational unit. The same restructuring that killed the AGI clause in the OpenAI contract treats GitHub as another lever, not a product with its own roadmap. ^[7]

The reliability post is signed by the CTO. The security disclosure is signed by GitHub's CISO Alexis Wales. ^[1] No one is signing for the platform as a whole, because no one's job is the platform as a whole. Orosz argues that explains the dysfunction. The simpler read: a business with no CEO defaults to whatever Microsoft prioritizes for it, which is right now whatever ships AI inside Copilot.

Who loses: customers who used to count on GitHub being run as a product. Who wins: GitLab, Forgejo, and self-hosted alternatives in conversations the platform team has not had to have for ten years.

What should teams do after the GitHub disclosure?

Three things, in order of urgency:

1. GHES users: patch to a fixed release today. Grep your audit logs for push operations with semicolons.
2. Merge queue users: audit recent squash merges in groups of 3+ PRs against expected base commits. The window is April 22-23.
3. Everyone: decide if your build, deploy, or compliance pipeline silently assumes git on GitHub is deterministic. If it does, write that assumption down somewhere it can be challenged.

Migration is the obvious overreaction. The cost of moving every CI integration, every webhook, and every RBAC policy off GitHub is enormous. The honest move is smaller: stop assuming, start verifying. The same lesson the Axios npm supply chain attack handed teams who treated package registries as boring infrastructure.

Key takeaways

• CVE-2026-3854 was a one-command server takeover. A crafted git push with injected options reached unsandboxed code execution on GitHub's servers. CVSS 8.7. Patched on github.com in 75 minutes.
• Cross-tenant blast radius on GitHub.com. The git service user has access across tenants. Wiz reached millions of repositories from outside organizations.
• The merge queue regression is the more interesting failure. A security bug compromises confidentiality. A merge queue bug compromises the developer's mental model of what merge means.
• The CTO's order is the news. "Availability first, then capacity, then new features." If that order needed restating, the prior order was something else.
• Three failures, no CEO. A platform without a head bleeds correctness and availability simultaneously, and signs incident reports with whichever C-suite is available.

I write more of these on LinkedIn, X, and Instagram. Usually shorter, sometimes as carousels. If this resonated, you'd probably like those too.

Sources

Footnotes

1. Securing the git push pipeline: responding to a critical RCE vulnerability (GitHub Security Blog) [↩] [↩ ^[2]] [↩ ^[3]] [↩ ^[4]]

2. GitHub RCE Vulnerability, CVE-2026-3854 (Wiz Research) [↩] [↩ ^[2]] [↩ ^[3]] [↩ ^[4]] [↩ ^[5]] [↩ ^[6]]

3. An update on GitHub availability, by Vlad Fedorov, GitHub CTO [↩] [↩ ^[2]] [↩ ^[3]]

4. Tom Elliott on the merge queue regression [↩] [↩ ^[2]]

5. Gergely Orosz on the GitHub data integrity incident [↩]

6. Mario Zechner: "this is not a dependable platform anymore" [↩]

7. Gergely Orosz on GitHub's missing CEO [↩]