One git push broke GitHub. The lesson is bigger than GitHub.

Last week, security researchers at Wiz revealed a flaw in GitHub that allowed any logged-in user to execute their own code on GitHub's servers using a single command. One push. Full takeover.

GitHub fixed it in hours. But at the time of disclosure, 88% of self-hosted GitHub instances were still vulnerable. The bug is now tracked as CVE-2026-3854.

The interesting part is not the bug. It is why the bug existed in the first place, because the same reason shows up in almost every modern app we audit.

What actually happened, in plain terms

Picture a relay race. When you push code to GitHub, your push gets handed off between four different internal services before it lands. Each service was built by a different team, in a different language, and each one trusts the team before it.

To pass information between them, GitHub used a simple format: a list of settings separated by semicolons. Things like file size limits, security flags, which folder to look up scripts in.

The first service in the chain copied user input into that list without removing semicolons. So a clever user could sneak in extra semicolons and inject their own settings, overriding the real ones. The next service down the line had no way to tell the difference.

By chaining three injected settings together, the researchers flipped a switch that turned off security sandboxing, redirected where the server looked up scripts, and got it to run any program on the system as a privileged user.

Once they had that, they could read files belonging to other GitHub customers on the same server.

One missing safety check, repeated across a chain of services, ended in cross-tenant data exposure on the world's largest code platform.

Why this matters far beyond GitHub

Every modern app looks a bit like this now. Multiple services, multiple languages, talking to each other over internal channels. Especially apps shipped fast with AI assistance, and especially AI agent products where data flows through layers of tools, prompts, and executors.

The same three patterns that broke GitHub show up constantly:

1. A team trusts the team before them in the chain. Service A says "the gateway already validated this." Service B says "well, A would have validated it." Nobody validates.
2. Settings get overridden silently when the format used to pass them allows duplicates.
3. Development-only code paths leak into production, gated only by a flag that turns out to be controllable.

None of these are exotic. They are the everyday consequence of building fast across multiple components without anyone explicitly tracing where user input flows.

What we do about it

The only thing that catches it is a human reading the actual flow of data and asking "what if the assumption breaks here?"