Ghosts on GitHub: 10,000 Fake Repos Spreading Trojans Target Devs

What would you do if you searched for your open-source project on Google or Bing, only to find an identical repository hosted by an entirely unfamiliar account?

This is not a standard fork. It is the beginning of a shocking revelation: over 10,000 GitHub repositories are actively distributing Trojan malware, specifically targeting automated tools (AI agents) and unsuspecting developers.

This massive supply chain attack was recently exposed by Orchid, a solo developer who detailed the investigation on orchidfiles.com. The campaign highlights a highly sophisticated mechanism used by bad actors to game search engines, bypass GitHub's native heuristics, and slip past automated security scanners.

The Perfect Camouflage: Building "Trust"

The attack begins with spoofing. The threat actors clone an existing, legitimate repository, preserving the entire commit history and contributor list. To anyone visiting, the repository appears credible, built over months or years by trusted community members.

However, every few hours, a new commit is pushed. It makes a single change: updating the README.md file to append a download link to a ZIP archive containing malware. To keep the repository at the top of "recently updated" lists and avoid pattern detection, the attackers continuously delete the previous commit and force-push the identical update.

The malicious ZIP archive typically contains four distinct files:

• Application.cmd or Launcher.cmd (execution script)
• loader.exe or luajit.exe (main malicious binary)
• A randomized data file containing the payload (e.g., .cso or .txt)
• The lua51.dll dynamic link library

Shockingly, if you run the direct ZIP download link through VirusTotal, it returns 0 warnings (completely clean). The malware only triggers detection once the ZIP file itself is downloaded and scanned directly, indicating a smart bypass of automated link-based scanners.

How 10,000 Malicious Repositories Were Uncovered

To identify the sheer scale of this campaign, Orchid turned to gharchive, a service that records public GitHub events. By analyzing 16 million push events over a five-day span, Orchid filtered the list down to 3,000 repositories that were updating multiple times a day.

By refining the script to target specific behavioral patterns (such as commits containing only README changes titled "Update README.md"), Orchid made an alarming discovery:

• Over 40,000 repositories exhibited suspicious update frequencies (1 to 24 times a day).
• Of those, 10,000 repositories precisely matched the payload pattern containing the Trojan horse ZIP file.

Even more concerning is that this campaign has been running silently for at least 18 months (dating back to early 2025) without being flagged or auto-deleted by GitHub's defense systems.

Why Target Niche, Low-Volume Repositories?

Instead of spoofing ultra-popular repositories like React or Vue, which would immediately draw attention and manual reviews, the attackers focus on smaller, niche projects. This approach offers several tactical advantages:

1. SEO Poisoning: Niche projects represent low-volume search terms. The cloned, malicious repositories can easily rank on the first page of Google or Bing, tricking developers looking for the original tool.
2. Targeting AI Agents: Many modern AI agents are programmed to fetch dependencies or tools automatically using GitHub tags. By constantly updating their commits, these malicious repos stay fresh on GitHub's active tags feed, increasing the chances of being crawled and executed by automated pipelines.
3. Bypassing Native Defenses: The constant force-pushing and deletion of commits prevent static security scanners from building a reliable historical fingerprint of the malicious repository.

GitHub's Slow Reaction: A Lingering Issue

The response from GitHub has been lackluster. It took over a month for GitHub to remove the initial batch of reported repos. While GitHub did eventually purge the 10,000 repositories discovered in Orchid's initial list, the threat actors simply spun up new ones.

Running the script a few days later revealed a fresh batch of cloned, malicious repos. GitHub has not integrated behavioral pattern scanning for this specific attack vector; they remain entirely reliant on manual abuse reports.

Key Takeaways for Developers

This incident serves as a stark reminder that software supply chain security is a continuous battle. To safeguard your development environment:

• Double-check Repository URLs: Always verify the absolute URL and the publisher's profile before cloning a repository or running code. Do not trust commit counts or contributor names at face value.
• Be Skeptical of ZIP links in READMEs: Legitimate open-source projects rarely require you to download a random .zip file from an external link to get started.
• Implement Guardrails for AI Agents: If you build or use autonomous AI agents with package installation capabilities, strictly limit their network access and enforce sandboxing. Only allow package retrieval from verified registries (like npm or PyPI) rather than cloning arbitrary GitHub repos.

Keep your guard up, because the ghosts on GitHub might be hiding behind the next innocent-looking commit.

---

Content assisted by AI (Amy 🌸). Reviewed by the author.