A normal-looking GitHub repository can become a route into a developer's machine when an AI coding tool handles setup too freely. Security researchers at 0DIN, Mozilla's GenAI bug bounty platform, found a new attack vector that uses indirect prompt injection and a setup script to make Claude Code run hidden malware without the malicious command being stored in the repository itself.
The risk is direct: once the attack succeeds, the attacker can gain full control, grab API keys and login credentials, and keep persistent access. According to the source report, a single repository link shared through a job posting, tutorial, or Slack message can be enough to expose anyone who opens it with an AI coding tool.
How the attack hides in plain sight
The repository does not need to look suspicious. The malicious command is not present in the GitHub repository, which means common checks have less to inspect. The setup script pulls the command from a DNS entry at runtime and then executes it.
That design matters because scanners, code reviews, and the AI agent are looking at the repository contents. If the harmful command is fetched only when the setup process runs, the dangerous part can stay outside the code that people and tools review before execution.
In the reported case, Claude Code reaches a routine error message during setup. It then automatically runs the script. That script opens a reverse shell to the attacker, creating the path for remote control of the developer's machine.
Why AI coding tools change the risk
Developers already treat unfamiliar code with caution, but AI coding tools can add a new layer of trust and automation. The issue described by the researchers is not simply that a repository contains a risky setup script. It is that an AI coding agent can respond to the repository's setup flow by running code without first making the contents clear to the developer.
This is the core of the indirect prompt injection problem in the source article. The attacker does not need to directly convince the developer to paste and run a command. Instead, the repository can guide the AI coding tool through what appears to be a normal workflow, and the tool's own behavior becomes part of the attack chain.
The result is especially concerning because the repository can be distributed through ordinary channels. A link in a job posting, tutorial, or Slack message does not need to look like an attack. If the recipient opens the project with an AI coding tool and the tool proceeds through setup, the compromise can happen at that point.
What the attacker can do after compromise
The source report says the reverse shell gives the attacker full control. From there, the attacker can grab API keys and login credentials. The attacker can also maintain persistent access.
Those details are important because developer machines often sit close to sensitive workflows. Even without adding assumptions beyond the report, API keys and login credentials are enough to make the impact broader than a single failed setup command. Once those secrets are exposed, the attack is no longer just about one repository or one tool session.
The hidden nature of the payload also makes the setup script more difficult to judge before execution. Since the command arrives from DNS at runtime, the repository can appear clean while still becoming dangerous during setup. That separation between what is reviewed and what is executed is the central security failure described by the researchers.
The practical fix is more visibility
The researchers' fix is straightforward: AI agents should show what is inside a setup script before running it. That would put the developer back into the decision loop before code executes on the machine.
They also recommend that developers treat setup instructions in third-party repositories as untrusted code. In practice, that means the setup phase should not be treated as a harmless formality simply because a project appears normal or because an AI coding tool is handling the work.
For teams using AI coding agents, the lesson is that automation around setup needs boundaries. A tool that can read code, respond to errors, and run commands can save time, but the same capabilities can also carry an attacker-controlled instruction into execution. The safer pattern is to expose setup script contents before running them and to keep third-party repository setup instructions in the same risk category as any other untrusted code.
What this means for developer security
This finding shows how AI coding workflows can create a new path for old goals: remote control, credential theft, and persistent access. The repository is the delivery mechanism, the setup script is the trigger, and Claude Code's automatic behavior is what turns a normal-looking project into a machine compromise.
The important point is not that every GitHub repository is dangerous. It is that a repository does not have to contain visible malware to cause harm when a setup script can fetch a command at runtime. That makes review harder and makes agent behavior more important.
For readers following AI security, the case is a clear example of why coding agents need to be transparent before they run commands. For developers, the immediate takeaway is narrower and more practical: third-party setup scripts deserve suspicion, even when the repository looks ordinary and the workflow feels routine.