Someone Cloned 10,000 GitHub Repos to Spread Malware Through Readme Files

A developer in Brazil noticed something odd in February 2026. He searched for his own project on Bing and found a perfect copy with the same name, same description, same commit history. Someone had cloned his entire repository. The only difference was a new commit, added an hour earlier, that dropped a link to a zip archive in the readme.

He found a second copy the same week while browsing GitHub tags. Same pattern. Cloned history, fresh commit, zip link in the readme. Then he watched both repos. Every few hours they deleted the commit and pushed it again, keeping the link alive while resetting the timestamp.

He reported them to GitHub. Two weeks, no response. He posted in GitHub discussions. Three replies came back, all clearly AI-generated slop, useless. A month later GitHub finally took them down.

But the question nagged at him. If there were two, there were probably more.

How he found them all

The researcher, who publishes under the handle "theorchid," decided to scan all of GitHub for the same pattern. The problem: GitHub has roughly 500 million repositories. At 5,000 API requests per hour, a brute-force scan would take years.

He used a service called gharchive that logs every public GitHub event. He downloaded five days of event data, 16 million commit pushes, and filtered for repos that get updated between 2 and 10 times every 10 hours. That narrowed it to 3,000 candidates.

Then he applied stricter filters. The commit had to come from a real user, not a bot. More than a month had to have passed between the last two commits. The repo needed multiple contributors.

After all that filtering, 14 repositories matched the full pattern. Fourteen, out of 500 million.

The zip archives they linked to contained four files: a cmd launcher, an executable (often named loader.exe or luajit.exe), a random .cso or .txt file, and lua51.dll. VirusTotal detects nothing if you submit the URL alone. Upload the actual zip and it flags a trojan.

What this means for AI coding tools

This story matters for anyone building with AI, and it matters more than you might think.

The immediate lesson is about code provenance. These repos looked legitimate. They had real commit histories copied from active projects. A developer searching for a dependency, browsing GitHub results, could easily land on one of these clones and pull the malicious code into their build.

But there's a second layer. When the researcher reported these repos and asked for help, the responses he got were AI slop. Generic, unhelpful, dismissive. The tools we're told will accelerate development were used to wave away a real security problem.

AI coding tools are getting better at generating code. They are not yet reliable at judging whether a stranger's GitHub repo is safe. That judgment still requires a human who understands the project, checks the commit graph, and notices when something feels off.

What you can do about it

Check the commit history before you clone anything. Real projects have varied commit messages, different authors over time, and meaningful changes between commits. A repo where the only recent activity is "Update README.md" every few hours is worth a closer look.

Look at the contributors. These fake repos had multiple contributor names attached (copied from the originals), but the commit patterns were identical across all of them. One author pushing the same change on a schedule is a red flag.

Use gharchive or similar tools if you're running a larger team. The researcher's script, the Git Malware Finder, is available on GitHub. Run it periodically against the dependencies in your own projects.

And maybe don't trust a readme link to a zip file. In 2026, we should probably know better.

The open question

Fourteen confirmed repos is a tiny number. The researcher thinks the real count is likely higher, possibly much higher. The 10,000 figure in some headlines refers to the broader campaign he initially tracked before GitHub took those down. The 14 are the ones his filters caught recently.

Either way, the technique works. Clone a real project, add a malicious link, push it on a repeat schedule. It's low effort and it targets the exact trust that open source depends on.

The fix isn't complicated. GitHub could flag repos that copy commit histories from other projects. VirusTotal could scan readme links by default. AI tools could learn to say "I don't know" instead of generating confident-sounding dismissals.