> Published: 2026-06-29 · Category: Research / Security > Source: The Decoder — Claude Code runs a GitHub repo's hidden malware without verification, giving attackers full control
What happened
On June 29, Mozilla's GenAI bug bounty platform 0DIN published research describing a new attack path that lets an apparently completely normal GitHub repository take full control of a developer's machine the moment Claude Code opens it.
The attack chain:
1. An attacker builds a GitHub repo that looks legitimate — professional README, tests, documentation.
2. The repo contains a setup script (setup.sh / install.sh / Makefile, etc.) with a command whose real content is not in the repo — it lives in a DNS record.
3. A developer opens the repo with Claude Code, which encounters an ordinary-looking error during the setup phase.
4. Claude Code automatically runs the setup script to "fix the error." The script performs a DNS lookup, retrieves the actual malicious payload, and executes it.
5. The payload opens a reverse shell. The attacker takes over the machine — stealing API keys, login credentials, and SSH keys, and maintaining persistent access.
The key point: the malicious code never exists in the repository — not in git history, not in the filesystem, not in the README. It only exists in a DNS record. This means:
- Standard code scanners can't find it;
- Human code review can't see it;
- Even the AI agent can't see it — it's outside the agent's view.
- Anthropic had made no public response as of 09:30 Beijing time, June 30;
- 0DIN's report includes no CVSS score or evidence of in-the-wild exploitation, but the generality of the "DNS channel + auto-setup" combination is high;
- Whether other agents (Gemini CLI, Cursor CLI, Aider, Continue.dev) are similarly affected requires independent verification — tools with IDE sandbox isolation like Cursor may have smaller exposure, but terminal-only agents are almost certainly on the same risk surface;
- Defensively, there is no silver bullet yet. The most practical interim measures: never let an agent auto-run setup scripts, or place external repos in a read-only container before letting an agent operate on them.
It requires an agent that triggers the setup script, actively querying DNS to "pull in" the payload. Claude Code is the first agent verified to do this; other similar tools (Gemini CLI, Cursor, Aider) are theoretically exposed to the same risk surface.
0DIN's suggested fix is simple: agents should display the contents of any setup script to the user before running it. But none of today's agents do this — because "automatically running setup scripts" is one of the productivity features they advertise.
Deep dive
Why is this a supply chain attack rather than a prompt injection attack?
Over the past 18 months we've seen many prompt injection stories — attackers stuffing malicious instructions into READMEs, issues, or commit messages so the agent executes them while reading. But those attacks have a "fingerprint": they are written in a file, catchable by git blame, code review, or static analysis.
This attack is fundamentally different. The malicious payload is entirely absent from the git repository — it's in DNS. DNS records are designed to be dynamically modifiable (today an IP can point to 1.1.1.1, tomorrow somewhere else), so attackers can swap payloads between "victim opens the repo" and "security researcher reviews the repo."
This is a neglected attack surface: the agent's own behavior triggers real-time queries to external network resources, and nobody has audited that query path as a potential trust chain.
"Auto-running setup scripts" is an implicit promise agents make.
When you open a repo with Claude Code, it automatically runs npm install, pip install, make, cargo build — that's the agent's "convenience." The flip side of convenience: the agent is making a trust decision on your behalf — deciding "this code is safe to execute."
When a human developer did this, they would personally look at setup.sh. When an agent does it for you, it silently makes the promise "I've read this code and it's safe." That promise was never audited — until now.
Background on 0DIN.
0DIN is Mozilla's GenAI bug bounty platform launched in 2024, specifically for prompt injection, jailbreak, and agent privilege escalation vulnerabilities. This disclosure went through 0DIN's normal bounty process — meaning it was responsible disclosure, and Anthropic should have had advance notice. As of writing, no public response from Anthropic has been seen.
Why it matters
1. The trust model of AI coding is being rewritten. Previously you trusted a repo because you trusted its code; now you trust a repo because you trust that "the agent reading it won't make decisions you don't know about." Nobody has audited this new layer of trust. 2. DNS becomes a new attack channel. Any design where "the agent queries external network resources at runtime" needs reassessment — including package installs, CDN resources, CI scripts, and documentation links. 3. AI coding governance in enterprises becomes a compliance issue. A developer at a financial firm opening an "apparently normal" external repo with Claude Code could trigger a leak of internal sensitive credentials — theoretical three months ago, now PoC-verified. 4. "Auto-run setup" is turning from a productivity feature into a liability. Every agent's automatic environment setup will need redesign — either "show first, ask second" or sandboxed execution.