A Solo Researcher Found 10,000 Cloned GitHub Repos That Outrank the Originals. Here's the 10-Minute Check Before You Download Anyone's ZIP.
A solo researcher going by Orchid found roughly 10,000 fake GitHub repositories quietly distributing crypto-stealing malware, and the detail that should make you sit up is how convincing they are. Each one is a clone of a real project: the full commit history, the real contributor list, the original README. The attackers changed exactly one thing: they added a link to a downloadable ZIP archive. The activity was first flagged on June 18, and some of these clones had been evading GitHub's automated detection for over a year.
The reason this matters to a solo developer specifically: you find code the same way the attack wants you to. You search a problem, you click a repo, you grab the thing. This campaign is built around that exact reflex.
Why the clones win
The clever part isn't the malware, it's the distribution. The attackers don't bother cloning famous, established projects where a fake would stick out. They clone newer repos, and because the clone is a near-perfect copy with real history and real stars-worth of legitimacy signals, the fake frequently ranks above the original in search results. You go looking for a tool, the first hit looks exactly like the project you wanted, and the only difference is a friendly "download the release here" ZIP link that the real maintainer never put there.
There's a second trick that tells you how deliberate this is. The fake repos periodically delete their most recent commit and push an identical one back, always named "Update README.md," every few hours. Orchid's read is that this constant churn is designed to confuse GitHub's security scanning: keep the repo looking freshly active and slightly different each pass, so automated detection has a harder time fingerprinting it. Whatever the exact mechanism, it worked well enough to hide 10,000 repos for a long time.
Because GitHub's team hadn't responded to earlier disclosures and there were far too many repos to report one by one, Orchid did the open-source thing: shipped a detection tool, Git Malware Finder, along with the full list of the 10,000 identified repositories. That's the part you can actually use.
The thing that breaks you isn't sophistication, it's a reflex
Read this campaign honestly and it's not a deep technical exploit. There's no clever memory corruption, no zero-day. It's social engineering aimed at one specific developer habit: search, find a repo that looks right, download and run the artifact it points to. The malware is mundane. The delivery is the whole attack.
That's actually good news, because reflexes are fixable. You don't need a new tool or a security budget. You need to notice the two seconds where you go from "this looks like the project" to "I'll run what it tells me to," and put a check in that gap.
The 10-minute habit that closes the gap
Here's the routine I'd build, and it costs almost nothing once it's automatic.
Never run code from a ZIP that a README links to. This is the single highest-value rule, because it's the entire payload mechanism here. Legitimate projects distribute through the package registry, through GitHub Releases with attached, named artifacts, or through git clone of the actual source, not through a "download this archive" link dropped in the README body. The moment a repo's install path is "grab this ZIP," treat it as hostile until proven otherwise.
Check that you're on the canonical org or user. Before you trust a repo, ask where the project actually lives. The real homepage, the package on npm or PyPI, the docs site: they all point at a specific GitHub org or username. If the repo in front of you isn't that one, it doesn't matter how good the history looks. A clone copies the history; it can't copy being the official account.
Prefer artifacts with provenance. When you do pull a release, favor packages and binaries that carry signing or build provenance over a raw ZIP a stranger uploaded. The supply chain has spent two years adding exactly these signals (trusted publishing, signed releases) because raw archives are the soft spot.
And if you want a backstop, Orchid published the repo list and Git Malware Finder. You don't have to wire it into CI to get value; even knowing the list exists changes how you treat a too-perfect-looking clone.
What this says about where security actually lives now
The uncomfortable lesson is that the platform's automated detection is not your safety net. These clones sat on GitHub for over a year. A single person found them, not the platform's scanning. If your model of supply-chain safety is "GitHub would have caught it," this campaign is the counterexample, sitting in your search results.
For a solo operator, that's not a reason to panic. It's a reason to internalize that the last line of defense is your own habit at the moment of download. You are the human in the loop, because there isn't another one.
What I'd actually do
This weekend, make the ZIP rule permanent: if installing something means downloading an archive a README points to, you stop and verify the repo is the canonical account before anything runs. That one rule would have blocked this entire campaign.
Then, the next time you're about to clone something you found by searching rather than by following a link from the project's own site or package page, spend the extra 30 seconds to confirm you're on the real org. The attackers are betting you won't. Make them lose the bet.
This is a sensitive enough topic that it's worth saying plainly: if you think you already grabbed something from one of these clones, treat the machine as compromised: rotate any credentials and keys that were on it, and check the Orchid repo list against your history. Better an hour of paranoia than a drained wallet.
Author
Lukas
@lukcombinator