Clean GitHub Repo Tricks AI Coding Agents Into Malware

Can a clean GitHub repo really trick an AI coding agent into running malware?

Yes — and that is exactly what makes this class of attack so dangerous. In June 2026, researchers at Mozilla's Zero Day Investigative Network (0DIN) showed that a GitHub repository containing no malicious code at all can still push an AI coding agent into downloading and executing a hidden payload. The repo passes scanners, passes human review, and passes the agent's own judgment, because the malice lives outside the files entirely.

The trick exploits the agent's helpfulness. Tools like Claude Code, Cursor, GitHub Copilot, and Gemini CLI are built to clone a project, read the instructions, hit an error, and fix it autonomously. The attacker simply designs the repo so that the obvious fix is to run a command that quietly pulls instructions from attacker-controlled infrastructure. Below is how the chain works, what it steals, and the hosting and workflow choices that decide how badly it hurts.

How the attack actually works: three benign parts, one nasty whole

The 0DIN proof-of-concept is elegant precisely because no single piece looks wrong. Each component is something you would shrug at in a code review. Stitched together, they form a working remote-execution chain.

The three stages

• A repo that looks normal. Standard install and initialization commands, a sensible README, ordinary structure. Nothing a static scanner or an AI reviewer would flag.
• A package designed to fail. A Python package intentionally errors out until it is 'initialized,' and the error message helpfully tells you (or your agent) to run an initialization command to fix it.
• An init script that phones home. That command runs a shell script which fetches a configuration value from an attacker-controlled DNS TXT record and executes it as a shell command — pulling the real payload from a place no repo scan ever looks.

Because the malicious instruction is delivered over DNS at runtime, the GitHub repository stays genuinely clean. The agent, trying to be useful, automates the whole sequence while thinking it is fixing a routine configuration problem. The human watching the terminal sees an agent 'resolving setup,' not an agent getting weaponized.

The repository is the bait, not the bullet. The payload never lives in the code you reviewed — it arrives at runtime, from infrastructure the attacker controls and your scanner never checks.

Why opening a repo is now more dangerous than cloning it

A parallel 2026 campaign — tracked as the Miasma worm — pushes the same idea further by abusing the auto-execution features baked into modern editors and agents. Here, attackers use stolen GitHub access tokens to slip a few extra files into popular repositories under an innocent commit like 'chore: update dependencies'. You don't even have to run anything by hand.

The danger is in config files most people never open during review. Each tool has its own auto-run hook:

As the analysis bluntly put it: cloning the repo is safe; opening it is not. No click, no manual command — just opening the folder in your editor or pointing your agent at it. Treat unexpected .claude/, .gemini/, .cursor/, and .vscode/ directories in a pulled repo as supply-chain red flags, because most review workflows scroll right past them.

What gets stolen — and why your hosting setup decides the blast radius

The goal is never the repo. It's your environment. Once the agent runs the payload, it inherits whatever that machine — or that build container — can reach. In the Miasma case the worm harvested credentials across AWS, Azure, GCP, Kubernetes, Vault, npm, and GitHub, then exfiltrated them to attacker-created public repositories used as dead drops.

This is where infrastructure choices stop being abstract. The same payload does wildly different amounts of damage depending on what the compromised environment can touch:

• Dev box with production keys in .env — catastrophic; the attacker walks straight into your live systems.
• Isolated dev environment, no production secrets — annoying but survivable; there's little of value to steal.
• Sandboxed, ephemeral build environment — best case; the payload runs in a throwaway container that's destroyed before it can persist.

The hard rule that contains all of this: never let a development or build environment hold production credentials. Keep deploys, secrets, and live infrastructure on isolated, access-controlled hosting rather than scattered across laptops. This is one practical reason teams favor providers like LaunchPad Host for separated, privacy-forward environments — a tricked agent on a dev machine should not be one cat .env away from your production cloud.

How to protect yourself: a practical checklist

You don't need to abandon AI coding agents — they're too useful. You need to stop trusting unknown repos by default and shrink the blast radius when something slips through. Work down this list:

1. Inspect before you open. After cloning, check for agent and editor config before launching anything: look for .claude/, .gemini/, .cursor/, .vscode/tasks.json, and suspicious test scripts in package.json.
2. Disable auto-execution for untrusted projects. Turn off folder-open tasks and session-start hooks until you've actually read them. Convenience features are the attack surface here.
3. Run unknown code in a sandbox. Clone and set up untrusted repos in an ephemeral container or VM with no access to your real keys, then throw it away.
4. Isolate credentials. Production secrets never live on dev machines. Use scoped, short-lived tokens and a secrets manager, not a committed or local .env full of live keys.
5. Watch what your agent runs. Log every command an AI agent executes, and be suspicious of any setup step that fetches data over DNS or curls a script into a shell.
6. Rotate on suspicion. If a sketchy repo touched a machine with credentials, rotate those keys immediately rather than hoping nothing fired.

What most coverage gets wrong about this attack

The headline reads like an indictment of AI coding agents, but the agents aren't the vulnerability — they're the automation that makes an old problem fast. Developers have always been social-engineered into running curl | bash from a README. The agent simply does it confidently, at machine speed, without the half-second of human hesitation that occasionally saves you.

The second misread is treating this as a 'scan your dependencies' problem. Software composition analysis looks for known-bad packages; here the package is fine and the repo is clean. The malicious instruction arrives at runtime over DNS, or hides in an editor config file your linter never parses. Dependency scanning is necessary and completely insufficient against this.

The real lesson is about trust boundaries, not tooling. Decide what an unknown repository is allowed to reach before you ever open it — which credentials, which network, which production systems. Pair AI coding agents with sandboxed setup, strict credential isolation, and hosting that keeps production firmly separated from experimentation, and a 'clean repo that runs malware' becomes a contained nuisance instead of a breach.