SURIQ
Mozilla's 0DIN research team published a proof of concept on June 27, 2026 that should change how you think about AI coding assistants. They got Anthropic's Claude Code to open a reverse shell on a developer's machine using a GitHub repository that held no malicious code. Nothing for a scanner to flag. Nothing the developer had to approve. The agent did it on its own, while trying to be helpful.
That last part is the whole story. The agent was not tricked into running an obvious payload. It was handed a normal-looking project, hit a setup error, and resolved the error the way it was built to: by running the command the project suggested. The reverse shell arrived three steps later, by which point the agent had already filed the work under routine setup.
How a clean repository talks your agent into a shell
The repository looks like thousands of real ones. Its instructions tell the agent to install dependencies and then run an initialization command, python3 -m axiom init. The trap is that the bundled package is built to fail until it is initialized, returning an error message that names the exact command to run next. Claude Code reads the error, treats it as a routine setup hiccup, and runs the suggested command to recover.
That command runs a small setup script, and the script does one quiet thing. It looks up a text record in the attacker's DNS, decodes the value it gets back, and runs that value as a shell command. The value is a reverse shell, so the result is a live connection back to the attacker carrying the developer's own privileges: environment variables, API keys, local configuration, and a place to persist. As 0DIN framed it, the agent never chose to open a shell. It chose to fix an error, and the shell was several indirection steps removed from anything it ever inspected.
Here is what makes it slippery. The payload is never in the repository. It lives in a DNS record the attacker controls, and they can rewrite it at any moment without touching a single file in the project. A repo your team reviewed and approved on Monday can deliver something entirely different on Tuesday, and your version history will show that nothing changed.
Inspect any single layer of your defenses and everything reads as normal. That is the point.
This is the third time we have watched an agent get turned against its user
Strip away the DNS trick and the shape is familiar. Earlier this year we covered how opening the wrong project could make Amazon Q run a repository's config file as the developer, AWS keys and all. We covered how a single web page could turn an AI agent against the machine it runs on. We covered how the app under test could hijack the AI agent sent to test it, and how a planted instruction turned Microsoft 365 Copilot into a path back out for stolen data. Different products, one root cause.
The common thread is not a bug in any single tool. It is the operating model. We have built assistants that read untrusted content, decide what to do about it, and then act with our credentials, all without asking. That autonomy is the feature people pay for, and it is the attack surface in the same breath. You cannot scan your way out of it, because there is no malicious code to find. The malicious instruction arrives as data the agent was told to trust.
Constrain the agent, because there is no patch coming
0DIN's recommendation to the vendors is sound: an agent should surface the full chain of what a setup command will run, including any script it calls and anything that script fetches at runtime. That is the right ask. While you wait for it, treat the agent like an untrusted contractor you handed a laptop and a network port.
- Take the agent off the network during dependency setup. If the install step has no outbound access, the DNS lookup that fetches the payload simply fails.
- Stop auto-approving commands. Require a human to confirm before the agent runs any shell command, and never let it silently run recovery commands when something errors.
- Run it in a sandbox with no real credentials. A container holding scoped, short-lived tokens and no host secrets turns a developer-privileged shell into a dead end.
- Watch your DNS. Outbound text-record lookups to freshly registered or unfamiliar domains from a developer machine are a known command-and-control channel, mapped to MITRE ATT&CK technique T1071.004. Alert on them.
- Rotate anything a developer box can reach. Assume the keys sitting in a developer's environment are the real prize, and keep their lifetime short.
This is where runtime detection earns its keep. A code review cannot see an attack that has no code, but a detection layer watching process activity and DNS catches the outbound call the instant the agent makes it.
The uncomfortable part is that the better these agents get at recovering from errors on their own, the more useful this technique becomes. Helpfulness is the exploit. Until the tools refuse to run what they will not fully show you, the safe assumption is that any repository your agent sets up unattended can reach back out to someone you never invited.
| Defense layer | What it sees | Why it misses the attack |
|---|---|---|
| Repository review | Ordinary setup files and a normal install command | There is no malicious code present to find |
| Static and dependency scanners | A script that performs a DNS lookup | A DNS query is not suspicious on its own |
| Network monitoring | A name resolution to a domain | It looks like ordinary DNS traffic, not data transfer |
| The AI agent | An authorized step to recover from a setup error | It was told to set the project up, so it complies |