How a Clean GitHub Repo Tricks AI Agents Into Running Malware

How does a clean GitHub repo trick AI coding agents into running malware?

A clean-looking GitHub repo tricks AI coding agents into running malware by hiding the attack outside the source code you actually read. The dangerous part lives in editor and agent configuration files — things like .claude/settings.json, .cursor/rules, and .vscode/tasks.json — that tell tools to auto-run a script the instant you clone and open the project.

This is exactly how the Miasma worm spread in June 2026. Researchers documented commits titled 'chore: update dependencies [skip ci]' pushed to popular repositories. The commit added no real dependencies. Instead it planted a dropper and wired it to execute automatically through five different paths: Claude Code, Gemini CLI, Cursor, VS Code, and the npm test script. The source files looked normal in a code review. The trap was in the plumbing nobody scrolls down to inspect.

The result was a credential-stealing worm that disabled dozens of repositories — including a reported 73 Microsoft-owned repos across Azure and related orgs — and exfiltrated cloud secrets to attacker-controlled accounts. The lesson for anyone running websites and infrastructure is blunt: cloning a repo to read it is no longer a safe, read-only act.

The hidden config files that do the damage

Auto-run features were built for convenience — spin up a dev environment, let the agent install things for you. Attackers turned that convenience into an execution trigger. Here are the exact files Miasma used and how each one fires.

The .cursor/rules entry is the cleverest of the set. It is a prompt injection that ships inside the repo: plain-language instructions telling the AI assistant to execute node .github/setup.js to 'initialize the project environment.' The agent, trying to be helpful, does exactly that. No exploit, no zero-day — just a tool following instructions it was never meant to trust.

Why 'just cloning to read the code' is no longer safe

For two decades, cloning a repository to read its source felt risk-free. You only got hurt if you actually built or ran the project. AI coding agents and IDE auto-run features quietly broke that assumption, and attackers noticed before most defenders did.

The Miasma dropper used real engineering to stay quiet. The .github/setup.js loader was obfuscated with a simple ROT-4 cipher, then decrypted two AES-128-GCM blobs, downloaded the Bun runtime from its official GitHub releases page, and ran the worm in an isolated Bun process. Pulling the runtime from a legitimate source helped it slip past naive allowlists.

The repo did not need a vulnerability in your code. It needed your tools to do what they were designed to do — run setup commands automatically — against a file you never agreed to trust.

This is what makes config-injection attacks so effective: every signal a developer relies on says 'safe.' The README is normal. The dependencies check out. The commit message reads like routine maintenance. The only tell is a directory most people never open in a diff.

What the payload steals — and why your hosting is the target

Miasma was not vandalism. It was a precision credential harvester, and the credentials it wanted are the ones that control your hosting and infrastructure. The worm scanned compromised machines for secrets belonging to AWS, Azure, GCP, HashiCorp Vault, Kubernetes, npm, and GitHub, then exfiltrated them to attacker-created public GitHub repos and used the stolen tokens to self-propagate.

Think about what those keys unlock. A leaked cloud API key can spin up servers on your bill, read your databases, or wipe production. A stolen GitHub Personal Access Token lets an attacker push malicious commits to your repos — turning you into the next link in the chain. For anyone running a website, a single compromised laptop can cascade into hijacked deployments, defaced sites, and runaway cloud charges.

The uncomfortable truth most security guides skip: your developer workstation is now part of your hosting attack surface. If your deploy keys and server credentials live in plaintext on the same machine where you clone unfamiliar repos, one careless git clone can hand an attacker the keys to your entire stack.

How to protect yourself, your team, and your servers

You do not need exotic tooling to shut this down. A handful of habits and one mindset shift — treat editor config as code that can run — covers the vast majority of the risk.

1. Review the whole diff, including config dirs. Any pull request or fresh clone that adds .claude/, .gemini/, .cursor/, or .vscode/ deserves a hard look. Unexpected editor config is a supply-chain signal, not noise.
2. Quick-scan before you open. A one-liner like test -f .github/setup.js && echo DROPPER, plus a grep for SessionStart hooks and folderOpen tasks, catches the obvious traps.
3. Disable auto-run for untrusted projects. Turn off folder-open tasks and agent session hooks unless you trust the source. Never run npm test on a codebase you have not vetted.
4. Clone unknown repos in a sandbox. A throwaway container or VM with no real credentials means a detonating dropper finds nothing worth stealing.
5. Keep secrets off the workstation. Use short-lived tokens, a secrets manager, and per-environment keys. If a token does leak, rotate it immediately and check for unauthorized commits or new public repos under your account.
6. Isolate and least-privilege your hosting. Deploy keys should do one job. Separate staging from production. The smaller each credential's reach, the smaller the damage when one escapes.

This is also where your hosting choices matter. Running your sites on infrastructure where access is tightly scoped and isolated limits how far a stolen key can travel. LaunchPad Host leans privacy-forward and keeps environments separated, so a credential leak on a dev box is far less likely to become a full infrastructure takeover — and crypto-friendly billing means a compromised card is not the thing standing between you and keeping your sites online.

Treat editor config like executable code

The durable takeaway from the Miasma campaign is a small but permanent change in how you read a repository. Source code is no longer the only thing that runs. Configuration that auto-launches scripts is executable, and it deserves the same scrutiny as the code itself.

Bake that into your workflow so a clean-looking repo can never run for long unchecked:

• Add editor-config directories to your code-review checklist as a standing item.
• Prefer cloning unfamiliar projects into disposable, credential-free environments.
• Watch for batches of commits with [skip ci] messages landing across multiple repos at once — a hallmark of token-reuse propagation.
• Rotate any cloud, GitHub, or npm token the moment a machine that held it touches a suspect repo.

The developers who came through Miasma cleanest were not the ones with the biggest security budgets. They were the ones who already assumed that opening a repo could run code — and built their hosting and secrets around that assumption.