How a clean repository tricks a coding agent into a reverse shell
Mozilla's 0DIN team showed that a public repo with zero malicious code can lead Claude Code to spawn a reverse shell — the real payload never sits in the repo, it is fetched at runtime from a DNS record.
What is this?
On June 29, 2026, SecurityWeek reported a proof-of-concept from Mozilla’s 0DIN team (researchers Andre Hall and Miller Engelbrecht) that answers an uncomfortable question: can someone who controls nothing but a public GitHub repository get code execution on anyone who opens that repo with an agentic coding tool — without committing a single line of malicious code? Their demonstration says yes. A developer asked Claude Code to do one ordinary thing, “get this freshly cloned project running,” and an interactive shell opened on their machine, connected back to an attacker’s server.
The result is a class of indirect prompt injection specific to coding agents. These tools are granted authority to read files, run shell commands, and make network calls. Once that authority is delegated, untrusted repository content — setup notes, README files, even the text of an error message — becomes an instruction channel that the agent follows without a human meaningfully reviewing each step.
How it works
The published proof-of-concept splits the attack into three pieces that each look boring in isolation. A repository ships normal-looking first-time-setup instructions in a README or issue. A local package is written to “fail closed”: if you use it before running an init step, it raises a plain, helpful error telling you to run that step — a completely ordinary developer pattern. And the init step calls a setup script that fetches a configuration value from an external source and runs it.
The critical move is where that configuration value comes from. Instead of living in the repository, it is served from a DNS TXT record the attacker controls. Conceptually the setup script does the equivalent of “resolve this DNS record, then execute whatever it returns” — the well-known dangerous anti-pattern of piping a fetched value straight into a shell. The repository never states what the value is, and the value is encoded, so no reverse-shell signature ever appears in plaintext on disk or on the wire. The actual payload is redacted here — a textbook reverse-shell one-liner — because it is not needed to understand the finding.
The chain then runs itself. The agent reads the files and installs dependencies, tries to use the app, hits the expected error, reads the error message, and runs the documented fix as routine error recovery. That fix triggers the script, the script resolves the DNS record, and the decoded command runs as the developer’s own user. As the researchers put it, the agent “never decided to open a shell — it decided to fix an error.” The reverse shell is three indirection steps removed from anything the agent actually evaluated: an error message it trusted, a script that fetched a value, and a DNS record it never saw. On the developer’s terminal, the only output is two lines of innocuous “environment ready” text.
Why it matters
The demonstrated impact is a full interactive shell running with the developer’s privileges. That exposes every secret in the environment — cloud keys, provider API keys, source-control tokens — and gives the attacker a window to establish persistence (drop an SSH key, add a scheduled job) before the shell closes. Because the payload lives in a DNS record rather than the code, it can be swapped at any moment with no commit and nothing for tooling to diff, and a single repository link shared in a job post, tutorial, or chat message reaches everyone who opens it with a coding agent.
What makes this hard is that no single defender sees the whole thing. Static analysis of the repo sees a DNS lookup. Network monitoring sees ordinary name resolution. The agent sees a pre-authorized setup step. The malice only exists in the composition — across the repository, the DNS infrastructure, and the developer’s trust in the agent — and none of the three systems is examined together. This is a researcher demonstration, not a reported breach; there are no confirmed in-the-wild victims, and it should be read as a warning about a structural gap rather than an active incident.
Defenses
The most direct fix is visibility into what a setup step will actually do. An agent should surface not just the command it is about to run but the contents of any script that command invokes and anything that script fetches at runtime, so that a “run the documented fix” action cannot silently expand into executing an out-of-band value. Treat command generation and command execution as separate trust decisions.
For teams and individual developers, the operational takeaways converge on least privilege and isolation. Run coding agents against unfamiliar repositories inside a sandbox or disposable container that holds no real credentials, so a hijacked setup step reaches nothing valuable. Do not export production secrets into the shell environment where an agent operates. Constrain outbound network egress to an allowlist so a freshly spawned shell cannot phone home, and be suspicious of setup flows that resolve DNS TXT records or pipe fetched content into an interpreter. Above all, treat setup instructions and scripts in repositories you did not write as untrusted code regardless of what an AI tool recommends — the same discipline the “lethal trifecta” and “Agents Rule of Two” guidance already prescribe: never let an unsupervised agent combine access to private data, exposure to untrusted content, and the ability to communicate externally.
Status
This is a disclosed proof-of-concept from a recognized research team, not a product vulnerability with an assigned identifier. The table summarizes the key facts.
| Item | Detail |
|---|---|
| Source | 0DIN (Mozilla), “Clone This Repo and I Own Your Machine” |
| Researchers | Andre Hall, Miller Engelbrecht |
| Disclosed | June 2026 (widely reported June 29, 2026 via SecurityWeek) |
| Technique | Indirect prompt injection → agent error-recovery → DNS-hosted payload → reverse shell |
| Demonstrated on | Claude Code; applies to agentic coding tools with autonomous shell access |
| Impact | RCE as developer, secret exfiltration, persistence |
| Status | Researcher PoC; no confirmed in-the-wild exploitation |
Both cited sources are from the last 30 days. The takeaway is architectural: as long as a coding agent will execute a “fix” without exposing what that fix ultimately runs, untrusted repositories remain an execution channel — and the defense lives in sandboxing, egress control, and treating third-party setup steps as untrusted code, not in scanning the repository for bad strings that were never there.