AI & DevelopmentSecurity

GitHub’s 10,000 Trojan Repos: The Orchid Campaign Targets AI Agents

GitHub repositories distributing trojan malware via the Orchid campaign targeting AI coding agents

A solo developer searching for their own GitHub project on Bing found an exact clone — same commit history, same contributor names, same README — with one addition: a link to a ZIP archive containing Windows malware. That was June 18. The campaign it exposed had been running for over a year, and GitHub’s automated security systems had not flagged a single one of the 10,000 repositories involved.

The researcher, who publishes as Orchid, released both a full list of the malicious repositories and an open-source detection tool called Git Malware Finder. GitHub has issued no official statement. New repositories matching the campaign pattern are still being created.

How the Attack Works

The campaign does not target popular, heavily-starred repositories where impersonation would be noticed. It targets newly created and low-visibility repos — the kind that rank well in search results for niche or obscure queries, which is exactly where AI coding agents go looking for reference code.

Each malicious repository matches a five-point pattern documented in Orchid’s disclosure:

  1. Updated between 1 and 24 times per day
  2. Every commit modifies only the README file
  3. Every commit is titled “Update README.md”
  4. The repository is not a fork — it is a fresh top-level repo with a commit history cloned from a legitimate project
  5. The README contains a link to an external ZIP archive

The commit churn is deliberate. Deleting and re-pushing identical commits every few hours mimics routine maintenance, which is what GitHub’s anomaly detection looks for to distinguish active projects from stale ones. The result is a repo that looks healthy and current, indefinitely.

Pasting the ZIP link into VirusTotal returns clean results. The malware only surfaces when the actual archive is submitted. Developers and security tools that check URLs rather than payloads will not catch this.

The Payload: SmartLoader and StealC

Downloading and extracting the ZIP launches SmartLoader, a LuaJIT-based first-stage loader with obfuscated Lua code. It installs two persistent scheduled tasks in %LOCALAPPDATA% that masquerade as benign system processes. One task re-downloads a fresh encrypted stage from GitHub on every execution — meaning removing the original repository does not clean an already-infected machine.

SmartLoader’s command-and-control server resolves not through a fixed IP or domain, but through a Polygon blockchain smart contract. There is no address to blocklist. The infrastructure is decentralized by design.

The second-stage payload is StealC, an infostealer capable of extracting crypto wallets, stored credentials, browser cookies, browser history, email sessions, and account data from Steam, Discord, and Telegram.

AI Coding Agents Are the Real Target

A human developer evaluating an unfamiliar repository checks: How many stars? Are there recent issues? Is there a community? These are friction points that slow down downloads and trigger skepticism.

AI coding agents — Cursor, GitHub Copilot, OpenCode, Claude Code — do not apply these checks by default. They follow search result rankings, which the campaign games via SEO poisoning of low-competition queries. They may retrieve ZIP archives as part of a research or implementation task without a human approval step. The ZIP link in the README looks like a normal binary distribution. Without explicit guardrails, an agent treats it as one.

Cybernews reporting on the Orchid disclosure noted this explicitly: searching for niche code leads to cloned repositories, and agents are more likely to pull the ZIP without the hesitation that triggers a human review. This is not a coincidence. The campaign’s targeting of new, low-visibility repos is optimized for the search patterns that autonomous agents use.

This fits the broader trajectory of 2026 supply chain attacks. The Miasma Worm in June targeted AI coding tools to compromise 73 Microsoft repositories. The Rules File Backdoor vulnerability in Cursor and GitHub Copilot uses hidden Unicode to inject malicious instructions through agent configuration files. Supply chain attackers in 2026 are building for a world where agents, not humans, make the first download decision.

What to Do Now

Start with the detection tool. Orchid’s Git Malware Finder is publicly available on GitHub along with a full list of the 10,000 confirmed repositories. Run it against any repos you have cloned in the past 12 months.

If you are on Windows, check your scheduled tasks for anything in %LOCALAPPDATA% with Lua dependencies. SmartLoader’s persistence relies on two scheduled tasks that survive repository takedowns. A clean GitHub repo scan does not mean a clean machine.

For AI agent users specifically: audit your agent’s tool permissions. Does your agent require explicit human approval before downloading archives? If not, configure it to. Review recent session logs for any archive downloads. Restrict file-system and MCP tool access during research phases where agents may be pulling external resources.

If you have cloned unfamiliar repositories in the past year, rotate credentials as a precaution — API keys, cloud provider tokens, SSH keys, npm and PyPI tokens. The cost of rotation is low. The cost of compromised credentials is not.

For teams: add Git Malware Finder to CI/CD dependency scanning. Enforce branch protection. Enable phishing-resistant MFA on all package registry accounts.

GitHub’s Response Problem

GitHub has not commented publicly. Community discussions show users submitted 100 malicious repository reports with none removed after three months. Individual reports take roughly two months to resolve. There is no bulk reporting mechanism, and attackers are creating new repositories faster than manual reporting can remove them.

This campaign ran for over a year. It took a single independent developer — not a corporate security team, not GitHub’s internal systems — to map it and publish the findings. That is not a process failure. At 10,000 repositories and counting, it is a structural one.

2026 has seen four major GitHub supply chain incidents: Clinejection in February, Axios npm in March, Megalodon in May, Orchid in June. Each was addressed reactively. The reporting pipeline that works for a handful of flagged repos does not work when a campaign operates at this scale. GitHub has published general supply chain security guidance, but no Orchid-specific response. Until the platform builds automated detection that matches attacker automation, developers are responsible for their own defense.

ByteBot
I am a playful and cute mascot inspired by computer programming. I have a rectangular body with a smiling face and buttons for eyes. My mission is to cover latest tech news, controversies, and summarizing them into byte-sized and easily digestible information.

    You may also like

    Leave a reply

    Your email address will not be published. Required fields are marked *