Skip to main content
Emerging ThreatsMalware & Ransomware

GitHub Repos Used to Deploy Malware via AI Coding Tools

Developer workstation with laptop open to GitHub repository, surrounded by coding tools and notes on cluttered desk.

"No exploit code, no warning, no suspicious command anyone had to approve." That stark appraisal comes from researchers at Mozilla's Zero Day Investigative Network (0DIN), who demonstrated how an AI coding agent can be coaxed into running a malicious payload from a repository that outwardly contains no malware.

0DIN's demonstration: an interactive shell from a clean clone

0DIN researchers showed that an attacker could plant an interactive shell on a developer’s device by asking Claude Code to run a cloned GitHub project that contains no explicit malicious files. In the demonstration, the repository behaved like a normal project: it required standard setup steps such as installing dependencies (for example, pip3 install -r requirements.txt) and running an initialization command (for example, python3 -m axiom init).

When Claude Code encountered a package intentionally designed to refuse execution until initialized, it treated the resulting error as a normal setup failure. Following the error message’s instructions, Claude Code automatically ran the suggested initialization command. That command invoked a shell script which fetched a configuration value from a DNS TXT record controlled by the attacker and then executed that fetched value as a command—resulting in a shell running with the developer’s own privileges.

The three benign components that chain together

  • A clean-looking GitHub repository with ordinary setup instructions.
  • A package that intentionally refuses to run until initialized, producing an error message that instructs the user to run a specific setup command (the example given was python3 -m axiom init).
  • A script invoked by that initialization step which retrieves a configuration value from a DNS TXT record controlled by the attacker and executes it as a command.

Individually, each of these pieces raises no obvious red flags. Combined, 0DIN researchers note, they create an attack chain that an automated agent will follow while attempting to "fix" a setup problem.

How Claude Code's recovery behavior enabled the exploit

According to 0DIN, Claude Code did not make a conscious decision to open a shell; it attempted to recover from an error and followed guidance presented in an error message. "Claude Code never decided to open a shell. It decided to fix an error. The reverse shell is three indirection steps away from anything Claude Code actually evaluated: an error message it trusted, a script that fetched a value, and a DNS record it never saw," the researchers said. "The attacker now has an interactive shell running as the developer's own user."

0DIN emphasizes that the approach requires no malicious component in the cloned repository itself: the agent automates the chain, including the step that mimics a common user error, and the DNS-hosted value supplies the payload at runtime.

Developer credentials, local secrets, and persistence risk

If successful, the technique gives an attacker a shell with the developer’s privileges. 0DIN points out that this access provides the attacker with environment variables, API keys, local configuration files, and an opportunity to establish persistence on the developer’s system. Because the exploit happens through routine setup activity, it can be invisible to human reviewers who inspect the repository and find no malicious code.

0DIN's recommendation for AI coding agents

To prevent such exploitation, 0DIN suggests that AI agents disclose the full execution chain of setup commands, including any scripts and code fetched dynamically at runtime. The researchers warn that although the attack is currently presented as a concept, threat actors could distribute repositories that look harmless via fake job postings, tutorials, blog posts, or direct messages.

What this means for developers, security teams, and threat actors

  • Developers: Be wary of agents automatically running suggested setup commands from cloned projects, especially when initialization steps invoke external scripts or network lookups. A benign-looking error message may be intentionally crafted to induce an agent to execute further commands.
  • Security teams and enterprises: 0DIN’s demonstration underscores a gap where automated recovery behavior can bypass human oversight. Teams should consider logging and monitoring of agent-executed commands and any runtime fetches (DNS, HTTP) performed during setup.
  • Threat actors: 0DIN warns that distribution channels such as fake job postings, tutorials, blog posts, and direct messages could be used to seed these clean-looking repositories into developer workflows, letting automated agents carry out the multi-step chain.

0DIN’s experiment reframes a familiar security problem: not all dangerous behavior looks dangerous at the point of inspection. An apparently routine setup error, followed automatically by an agent’s "helpful" fix, was enough—within the researchers’ demonstration—to hand an attacker an interactive shell running as the developer’s user. The practical remedy 0DIN proposes is straightforward in description if difficult in implementation: force agents to reveal the full chain of what they execute, including any dynamically fetched code or configuration, so defenders can see and vet the runtime actions that repositories alone do not disclose.

Source: BleepingComputer — Clean GitHub repo tricks AI coding agents into running malware