Over 9,000 Trojan GitHub Repos Built to Bait AI Coding Agents

A developer going by the alias Orchid published findings on June 18 that put a number to something security teams have suspected for a while: GitHub’s repository ecosystem is thick with trojan clones engineered to look legitimate. The count came out at 9,330 documented malicious repositories, derived from filtering 16 million GitHub commit events through the GH Archive public dataset. The real number is almost certainly higher — GitHub’s API rate limits capped what Orchid could verify.

The campaign has been running since at least early 2025. Prior research from Hexastrike had flagged 109 malicious repos. Orchid’s analysis suggests that figure was about one percent of the actual operation.

How the Campaign Works

The technique is not complex. An operator clones a legitimate open-source project under a freshly created GitHub account, strips the README of technical content, and replaces it with prominent download buttons pointing to ZIP files embedded directly in the repository tree.

That framing matters because it targets a specific mental model: developers (and AI agents) who find a repository through search expect to get source code, not an installer. The ZIP contains SmartLoader, a LuaJIT-based malware loader that uses Prometheus obfuscation to complicate static analysis.

What makes SmartLoader novel is its command-and-control mechanism. Rather than contacting a fixed domain that can be sinkholed or blocked, the loader queries a Polygon blockchain smart contract for its current C2 URL. The attacker can rotate infrastructure without touching the deployed malware. Defenders blocking by domain or IP see the old address; the loader has already moved on. SmartLoader then executes StealC through four in-memory decryption layers, targeting browser-stored credentials, cryptocurrency wallet files, and session tokens.

The malicious clones rank above the originals in GitHub search results. The mechanism is artificial activity: the operator runs automated scripts that delete and re-add files every few hours, making the clones appear more recently active than the real projects. GitHub’s search algorithm weights recent commit activity, so the fakes surface first.

The AI Agent Angle

Orchid specifically flagged that these repos were baiting AI coding agents, not just human developers. When Cursor, Claude Code, Copilot, or Gemini CLI needs to find an example repository, look up a dependency, or autocomplete a reference, it uses GitHub search. The same search manipulation that fools a developer also fools the agent.

Some of the malicious forks go a step further. Poisoned configuration files, specifically .cursorrules and .github/copilot-instructions.md, appear in forked projects alongside the malicious download mechanism. These files are read by AI coding agents at session initialization and carry authority close to a system prompt. If a developer clones one of these repos and opens it in Cursor or Claude Code, the agent may operate under instructions it never disclosed to the developer.

That particular technique connects to a broader research thread. Pillar Security demonstrated earlier this year that invisible Unicode characters embedded in .cursorrules files can silently instruct an AI agent to insert backdoors into all generated code, with the adversarial instructions remaining invisible in code editors and GitHub diffs. The 10,000-repo campaign adds scale to what was previously a proof-of-concept attack path.

Detection Is Not Easy

Standard supply chain tooling does not catch this. SBOM scanners and dependency auditors work at the package manifest layer. The threat here lives in repository content: a README, a ZIP file, a config file. Nothing in package.json or requirements.txt signals a problem.

Orchid’s methodology points toward the detection approach that does work: behavioral analysis of commit patterns. Legitimate projects do not delete and re-add files on a multi-hour cycle. Filtering commit histories for this churn signature, using tools like Git Malware Finder, can surface suspicious repos before they get fetched.

A few other signals:

• Repos with prominent “Download” or “Get Started” buttons that link to ZIP files rather than tagged Releases
• Account creation dates that postdate the project’s supposed history
• Repository names that exactly match popular packages but sit under unknown accounts

For AI-specific risk: audit any .cursorrules or AGENTS.md files that appear in repositories you did not write. If the content is unexpected or contains unusual Unicode characters, treat the repo as compromised.

Broader Context

The timing is not coincidental. AI coding agents have expanded the value of controlling what ends up in GitHub search results. When an agent autonomously fetches code examples, it does not stop to ask whether the repository owner is who they claim to be. That trust assumption is what the campaign exploits.

GitHub is removing flagged repos, but the operator keeps creating new ones. The blockchain C2 architecture means the malware’s infrastructure survives takedowns of individual repositories. Until AI coding agents implement stricter verification of repository provenance, the attack surface remains open.

References

• Orchid Files — I discovered a large-scale malware distribution on GitHub
• Byteiota — 10,000 Trojan GitHub Repos Are Targeting AI Agents
• TechTimes — GitHub Malicious Repositories: 10,000 Trojan Clones Evade Detection for Over a Year
• Pillar Security — The Agent Security Paradox: When Trusted Commands in Cursor Become Attack Vectors