A Clean-Looking Repo Can Still Hijack Your AI Coding Agent

You clone a repository. The README looks normal. There’s a Python package that, on first run, fails with a common-looking setup error and tells you to run one more command to fix it. If you’re using an AI coding agent to work through the setup, it reads that message and, trying to be helpful, runs the command for you. That command opens a reverse shell to an attacker’s server, and neither you nor the agent ever saw the malicious instructions, because they were never in the repository at all.

That’s the attack Mozilla’s 0din research team demonstrated in June 2026, and it’s worth understanding in detail because it doesn’t depend on a bug in any specific model. It depends on how agentic coding tools handle instructions that arrive through project content instead of through you.

How the chain actually works

The attack has four links, and each one looks unremarkable in isolation:

1. README with normal-looking setup instructions
        │
2. Python package engineered to fail on first use,
   prints a message pointing to an "init" command
        │
3. Init command runs a shell script
        │
4. Shell script resolves a DNS TXT record controlled
   by the attacker, pipes the content directly to bash
        │
   Reverse shell, running as the developer's own user

The key design choice is step 4. The actual malicious payload, the code that opens the reverse shell, isn’t written anywhere in the repository. It lives in a DNS TXT record the attacker controls off-site, fetched at the moment the script runs. That means static analysis of the repo finds nothing to flag: the script that’s actually present just does a DNS lookup and pipes the result to a shell, which is a legitimate pattern used by plenty of real installers. The dangerous part only exists for the seconds it takes to execute.

Why an AI agent makes this worse, not better

A human developer reading a “run this command to fix the setup” message has some chance of pausing, especially if the command looks like it involves network calls piped into a shell. An AI coding agent working through a task doesn’t have the same instinct by default. It’s optimizing for “complete the task the user asked for,” and if the repository’s own content tells it that running one more command is the way to fix a broken setup step, that instruction looks like part of the task, not an attack.

This is what security researchers call indirect prompt injection: the attacker never talks to the agent directly. They plant instructions in content the agent is going to read anyway, a README, an error message, a code comment, and let the agent’s own task-completion drive carry the payload forward. Unit 42’s broader research on this pattern found it works across web content generally, not just repositories, which tells you this isn’t a one-off trick, it’s a structural weakness in how current agents weigh “instructions from my user” against “instructions I encountered while doing what my user asked.”

The part that should get every team’s attention: this worked across agents built on models from multiple different vendors. It’s not a gap you close by switching tools.

What’s actually exposed

Once the reverse shell is live, the attacker has whatever the compromised process has. For a developer running an agent locally, that’s usually everything in the shell’s environment: cloud provider credentials, git tokens, package registry auth, API keys for whatever services the project touches. For an agent running in CI, it can be worse, since CI environments frequently hold deploy credentials with broader blast radius than a single developer’s laptop. And because it’s a reverse shell rather than a one-shot payload, the attacker has persistence, not just a single stolen secret.

What to change this week

1. Scope agent permissions to the task, not to your whole environment. If an agent doesn’t need access to your cloud credentials to fix a lint error, it shouldn’t have a shell session where those credentials are exported.
2. Treat “one command to fix it” instructions from repository content as a manual-approval step, particularly anything involving curl, DNS resolution, or piping output straight into a shell. That pattern is common enough in real installers that agents will keep proposing it; the fix is a human checking the specific command, not banning the pattern outright.
3. Run agentic workflows in isolated environments when the task involves cloning and executing code from a repository you don’t control. A sandboxed execution environment limits what a successful injection can actually reach, which is a different, complementary control to catching the injection itself. If you’re building this into your CI or agent tooling, our walkthrough of running untrusted code safely with Deno Sandbox covers one practical way to add that isolation layer.
4. Don’t assume this is caught by “the agent read the whole repo first.” The entire point of the DNS TXT record technique is that the payload isn’t present for the agent, or a scanner, to read in advance.

The uncomfortable truth here is that the attack surface isn’t the AI agent’s intelligence, it’s its obedience. An agent that correctly interprets “run this command to fix your setup” as a reasonable instruction is doing exactly what it’s supposed to do when the instruction is legitimate. The only way to catch the illegitimate version is to stop trusting repository content as a source of commands to execute without a human in the loop, the same discipline good engineers already apply to unsolicited scripts from strangers.