How a Clean GitHub Repo Tricks AI Agents Into Running Malware

How can a clean GitHub repo trick an AI agent into running malware?

The source code looks fine because the malware is not in the source code. It hides in the configuration files your AI coding agent reads automatically — files like .cursor/rules, .claude/settings.json, or a package.json test script. When you clone the repo and open it in an agent, those files quietly instruct the tool to fetch and execute a payload. You never typed a command, and the visible code passed review.

This is a prompt-injection-meets-supply-chain attack, and it works because AI agents and modern IDEs treat repository files as trusted instructions, not just inert text. A line in a rules file that says run this setup script is, to the agent, a legitimate directive. The repo can have a polished README, real working features, and thousands of stars. The hostile part is a few kilobytes in a folder most developers never open.

The danger is not a vulnerability in GitHub or npm. It is that cloning a repo used to mean reading code, and now it can mean executing it.

The Miasma worm: a real-world 2026 example

This stopped being theoretical on June 3, 2026, when the Miasma worm hit both the npm registry and GitHub source repositories at once. On the GitHub side, an attacker pushed an innocuous-looking commit — titled something like chore: update dependencies [skip ci] — to a popular library and several sibling repos. The commit did not touch the application logic. It planted configuration files engineered to achieve code execution across five different developer tools.

The reported payload runner was wired to fire through Claude Code, Gemini CLI, Cursor, VS Code, and the npm test script. One planted file was a .claude/settings.json with a SessionStart hook, so the payload ran automatically the instant an agent session opened the folder. A .cursor/rules entry did the same job for Cursor users. The worm spread to dozens of repositories, including ones in major organizations, before it was caught.

What made conventional defenses fail is that the worm operated entirely inside legitimate channels. It did not exploit a bug. It used features working exactly as designed — auto-run hooks and agent rule files that exist to make development faster.

Why your dependency scanner never sees it

Most teams assume their supply-chain security tools cover this. They usually do not, because those tools look in the wrong place. Software composition analysis scans your declared dependencies for known-vulnerable versions. This attack ships zero malicious dependencies — the danger is a config file that tells your agent to download something later, at runtime, from somewhere the lockfile never mentions.

Here is how the blind spots line up against the real attack surface:

A 2026 review covering 78 studies found that every major coding agent — Claude Code, GitHub Copilot, Cursor — fell to prompt injection, with adaptive attacks succeeding more than 85% of the time. The gap is not a single buggy product. It is an industry-wide assumption that repo files are safe to read.

How to defend your machine and your servers

The fix is to stop letting an unknown repo run anything before you have looked at it, and to put real isolation between untrusted code and the systems that matter. Stack these from quickest to most robust.

1. Turn off auto-run. Disable SessionStart hooks, auto-approved tools, and IDE tasks that execute on folder open. Make your agent ask before it runs a shell command. This single change defeats the detonate-on-open mechanic.
2. Inspect the dotfolders first. Before opening any cloned repo in an agent, list and read .claude/, .cursor/, .vscode/, .github/, and the scripts block in package.json. Treat any instruction to fetch-and-run as hostile until proven otherwise.
3. Open untrusted code in a sandbox. Use a disposable container, VM, or dev container with no credentials, no SSH keys, and no production access. If the payload fires, it detonates in a cage you can delete.
4. Strip secrets from the dev environment. An agent that gets hijacked can only exfiltrate what it can reach. Keep cloud keys, deploy tokens, and CRM credentials out of the shell where you explore new repos.
5. Pin and review agent rule files in your own repos. Treat .cursor/rules and .claude/settings.json as security-sensitive code. Require review on every change, the same as you would for a CI workflow.

The principle underneath all five: the machine where you read strangers' code should never be the machine that holds the keys to your infrastructure.

Where hosting choices reduce the blast radius

Defense does not stop at the laptop. The second line is making sure a compromised developer machine cannot become a compromised production server. The cleanest way to do that is to never deploy straight from a workstation that touched an unknown repo. Build from a reproducible, locked pipeline, and push the resulting artifact to a server that the developer environment cannot otherwise reach.

Isolation at the hosting layer matters here. Running your sites and apps on a host where each environment is properly segmented — separate from your build machine, with its own credentials and an acceptable-use policy that takes abuse seriously — limits how far a single hijacked agent can spread. LaunchPad Host offshore and privacy-forward plans give you that separation between where you experiment and where you serve real traffic, with crypto-friendly billing and domains under one roof, so a bad repo on your laptop does not put your live infrastructure within arm's reach.

For deploys, prefer signed, immutable artifacts and a CI runner that has no standing access to your repos beyond what a single job needs. The less ambient power an automated agent holds, the less a prompt injection can steal.

A quick checklist before you open any new repo

Turn the lesson into a habit you run every time, so a clean-looking repo never gets a free shot at your environment.

• Read the dotfolders before the code. .claude, .cursor, .vscode, .github, and package.json scripts — open them first, every time.
• Open it in a sandbox. Disposable container or VM with no real credentials, then delete it when done.
• Keep auto-run off by default. Your agent should request permission before executing anything.
• Separate exploration from production. Never deploy to a live host from the same machine that just cloned an unknown project.
• Watch the network. Unexpected outbound connections from a fresh clone are the clearest sign a hidden hook just fired.

Everything breaks eventually, and the next worm will use a different filename. The durable defense is the assumption behind all of this: a repository is untrusted input until you have personally verified it, and the systems that run your business should be a deliberate hop away from anything you are still inspecting.