He filtered 16M GitHub pushes and found 10,000 repos pushing the same Trojan

One clone, re-pushing the same commit every few hours

The original write-up (779 points in the thread) starts small. The author found two repositories carrying his project's name and full commit history, plus one addition: a link to a zip archive. The odd part was the rhythm. "Every few hours they delete the previous commit and push the exact same commit again."

The reason is search ranking. A fresh-looking, frequently-updated clone climbs GitHub's "recently updated" sort and ranks for niche search terms, so a user looking for the real tool lands on the fork and downloads the poisoned release instead.

How one repo became a 10,000-repo count

GitHub support took about two weeks to first respond and a month to act, so the author automated the hunt using GHArchive. He filtered roughly 16 million commit pushes over 5 days, started with 3,000 high-frequency repos, then refined for non-bot accounts, contributor history, and commit-message patterns. Searching for repos "updated between 1 and 24 times every 24 hours" surfaced 40,000 candidates, of which 10,000 exactly matched the campaign's pattern, 25% of the total.

The payload is a four-file zip: a .cmd launcher, a renamed executable (loader.exe, luajit.exe), a data blob, and lua51.dll. One reader pulled samples apart:

"the virus makes requests to three resources: a GET request to a website to retrieve IP information, a POST request to a Polygon RPC node (drpc), and a POST request to what appears to be the virus creator's server." — a reader who uploaded several archives to VirusTotal

That shape, Polygon RPC plus a callback to an unknown server, reads as crypto theft.

Why a link scan says clean but the file says Trojan

The evasion is mundane and effective:

"If you submit a link to the archive to VirusTotal, it will find 0 viruses. If you submit the zip file itself, it will detect a Trojan inside it." — a commenter quoting the file manifest

Someone who has tracked these campaigns before noted what makes them hard to enumerate: each repo is a new repository rather than a fork, with different contributors and different names, so finding one tells you nothing about the rest. The 16-million-push filter was the only way to see the whole shape.

A developer with a security-research bio described running into the identical playbook himself. Small useful codebases get forked, the distributable swapped for malware, the README rewritten for SEO; when he caught one it was reported and removed within 24 hours. The faster path, several noted, is automated scanning GitHub itself could run:

"the one thing we absolutely refuse to use AI for is to flag this kind of bullshit to protect users…" — a developer in the thread

The open-source trust model, used against itself

The campaign weaponizes the thing that makes GitHub useful: a public history that looks legitimate. As one reader put it, the principle that open source can't hide anything because the source is visible "just hasn't held up", because nobody inspects the code, and nobody checks that the binary matches it. A clone with real commits and a polished README clears that bar by default. Until GitHub treats commit-churn fingerprints as a signal, the detection burden sits with one developer parsing 16 million pushes on his own time, and the author notes GitHub deleted only the repos on his list, without re-checking for new ones.