Mozilla’s 0DIN researchers have published a proof-of-concept attack showing how a clean-looking GitHub repository can lead an AI coding agent into running malware without the malicious payload appearing in the repository itself.
The demonstration, published June 25 and reported by BleepingComputer on June 27, used Claude Code as the example agent. 0DIN’s setup chained ordinary project instructions, routine error handling, and a shell script that fetched a command from a DNS TXT record controlled by the attacker. The result was a reverse shell running with the developer’s own user privileges.
This is not a reported active campaign. It is still important because it fits the way developers increasingly use coding agents: clone a repository, ask the agent to get it running, and let the tool install dependencies, fix setup errors, and run commands until the project works.
How the attack works
0DIN’s researchers described the repository as boring on purpose. The project included normal-looking setup notes, such as installing requirements and running an initialization command. Nothing in the repository needed to look like malware for a human reviewer, static scanner, or the AI agent to flag it immediately.
The first step was a package that refused to run until it had been initialized. When used too early, it returned an error telling the user to run python3 -m axiom init. That is the sort of setup failure a coding agent is designed to resolve.
The second step was the dangerous one. Running the initialization command called a shell script that queried a DNS TXT record and executed the returned value as a command. In 0DIN’s example, that DNS value decoded into a reverse shell. The payload was not committed to GitHub, so there was no malicious file for ordinary repository review to catch.
0DIN summarized the trap this way: Claude Code did not choose to open a shell; it chose to fix an error. The malicious behavior was several steps away from the instruction the agent directly evaluated: a trusted error message, a setup script, and a DNS record the agent never inspected before execution.
Why this is different from ordinary dependency risk
Developers already know that unfamiliar dependencies and install scripts can be dangerous. The AI-agent version adds a second problem: the agent may connect benign-looking steps faster than a human would, treat setup failures as tasks to repair, and continue through a chain of commands because each individual step appears consistent with the project’s instructions.
The payload location also changes the review problem. A scanner looking only at the GitHub repository sees a setup script that performs a DNS lookup. A reviewer checking the Python package sees an initialization requirement. A developer watching the agent sees a tool attempting to resolve a normal setup error. The attack only becomes obvious when those pieces are evaluated together, including the content fetched at runtime.
If the chain succeeds, the attacker gets a shell running as the developer. That can expose environment variables, cloud credentials, GitHub tokens, local configuration files, SSH material, and other secrets that often live on engineering workstations. It can also give the attacker time to add persistence before the session closes.
What Anthropic’s own docs say about the risk boundary
Anthropic’s Claude Code security documentation says the tool uses strict read-only permissions by default and asks for approval before Bash commands that can modify a system. Its permission system lets users approve commands once or allow them automatically, while a built-in set of read-only commands can run without prompting.
The same documentation warns that users remain responsible for reviewing proposed commands, recommends virtual machines for untrusted scripts or external web services, and notes that no system is immune to all prompt-injection attacks. Its permissions guide also distinguishes normal approval mode from modes such as auto and bypassPermissions, with the latter recommended only inside isolated environments such as containers or VMs.
That distinction is central to the 0DIN example. The issue is not that every coding agent will automatically run every malicious command. It is that teams often relax prompts, pre-approve common commands, or run agents in environments that hold real credentials. Once the agent is allowed to execute setup and recovery steps, unfamiliar repositories become active code, not just text for the model to read.
What developers should change now
The practical response is to treat agent-run setup work like running an unknown installer, not like asking a chatbot for help. A repository from a job posting, tutorial, direct message, Discord thread, or random search result should not be initialized by an agent on a normal workstation that contains production credentials.
- Run unfamiliar projects in a throwaway container, VM, or cloud sandbox with no real secrets mounted.
- Keep AI coding agents out of shells that have long-lived cloud keys, GitHub tokens, package-publishing tokens, or production environment variables.
- Review setup scripts, package lifecycle hooks, shell pipelines, and network-fetching commands before approval.
- Block or prompt on commands that fetch and execute remote content, including patterns involving
curl,wget,dig,bash -c, pipes into shells, and decoded payloads. - Use project-specific permission rules instead of broad Bash allowlists, especially for unfamiliar repositories.
- Log agent command execution so security teams can reconstruct what ran, what fetched network content, and which credentials were exposed.
- Prefer ephemeral credentials for agent sessions, and rotate secrets after any suspicious setup run.
Enterprise teams should go further by setting managed permissions, disabling risky approval modes where possible, and requiring sandboxed execution for agent work on third-party code. The policy should cover local agents, IDE integrations, cloud coding environments, and CI agents because the same pattern can appear wherever an automated tool is trusted to install and initialize code.
The larger lesson for AI coding workflows
The 0DIN proof of concept lands at an uncomfortable point in agent adoption. Coding agents are becoming more useful precisely because they can recover from errors, infer missing steps, and keep working through messy setup tasks. Those are also the behaviors attackers can shape with repository instructions, package errors, scripts, and external configuration.
Static code review remains necessary, but it is no longer enough for agentic development. The review target now includes the full execution chain: commands the agent plans to run, scripts those commands invoke, network locations those scripts contact, and runtime values those systems return. A clean repository can still be dangerous when the payload lives outside the repository and the agent is trusted to connect the dots.
